Class structure for video editor
Hi!
My GUI looks like the timeline from a video editor. http://666kb.com/i/beo6m3j4ehr42wk8b.png
(It has nothing to do with video editing, but that's a useful analogy.)
Time runs from left to right. Along that timeline, the user can add events. The horizontal position determines when the event will be played.
When events are clicked, their properties can be changed in a panel on the side.
I need the following functionality:
* GUI-objects for events on the timeline
* Logic for these events (what happens when that event occurs?)
* a "property GUI" for each event
* a Timeline GUI, which combines the property page and the events
* Timeline Logic, which calls event logic in the appropriate order
Some problems that come to mind:
* Should Event GUI and event logic be in the same classes?
* Events are positioned in pixels on the GUI. But internally, their position is stored as the time at which they happen. Where should that conversion occur?
* Different event logic needs access to different subsystems: A music object needs access to the Sound Engine, for example.
What would be a clean class structure for this?
Language is C#, GUI library is Windows Forms.
[Edited by - Tubos on December 4, 2009 3:00:47 PM]
Quote:Original post by Tubos
* Should Event GUI and event logic be in the same classes?
Doesn't sound practical to me. They're two different things - one is part of the UI, the other part of the behavior and data of the program. Read up on MVC - Model, View, Controller. Basically, it's separating the data and logic (model), the representation / interface (view) and the (user) input handling (controller).
Quote:* Events are positioned in pixels on the GUI. But internally, their position is stored as the time at which they happen. Where should that conversion occur?
Events are not positioned in pixels - they are drawn, displayed, at that position. The conversion is typically done while drawing. Much like how, in a game, objects are not moved when the camera moves - the camera just determines where they are drawn. It translates world coordinates into screen coordinates, so to say.
Quote:* Different event logic needs access to different subsystems: A music object needs access to the Sound Engine, for example.
A base Event class likely makes sense here, since all events have some common data (position, duration, etc.) and functionality (place on timeline, remove from timeline, check properties, etc.). Each unique event type would derive from that Event class, but store specific data. You'll likely want a central place that constructs these Event objects, a place that knows all the required modules so it can construct every Event type based on it's needs.
For the properties, reflection may come in handy.
A clean class structure would be one that separates the information in the timeline with its representation on screen. Try to make as much logic as possible independent of the GUI, without forcing anything unnaturally. Then write a GUI system that manipulates it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement