- Undo/Redo support (which operations will support it), and how to implement it
- Back end support for effects and transition
I need to update my design document a bit: I actually want to make the UI a little more general. Instead of a "content-image" portion of each timeline object, I just want to have a "UI" portion. I want to be able to define custom UI for different kinds of media and effects that will appear within each box. The default "UI" will be a keyframe editor, but other UI modules could be constructed. The trick will be in choosing which UI will appear when. Perhaps a factory-based system could be used, mapping factory types to their appropriate UI. This would be good for plugins that want to define new source/effect types and then have UI for them.
The simple timeline broke somewhere between the time I stopped working on it and the end of the summer. I have no idea what's going on, but it's damned annoying. I'm kindof not that interested in maintaining the simple timeline anymore. I'd much rather focus on the advanced timeline, because really, advanced isn't that hard to deal with. The goal of the simple timeline was to be easy to implement, IMHO, and it's actually a little harder to work on than the advanced timeline at this point. But in any case, being able to switch back and forth is going to create complications that I don't really want to have to worry about.
Edward is working on switching PiTiVi and gstreamer over to git (from svn). When that happens I'll start maintaining my own branch where I can hack on some things a little more freely. In the mean time, my future commits will probably be related to bug fixes so that people can actually use the work that I did this summer.
Finally, There's one new feature I wanted to add to make the minimal feature set that the advanced timeline now support a little bit nicer: When you trim a source or drag a source in the timeline, I want the viewer to seek to the relevant edit point. I.e. when you move a source, you should see the point in the timeline just before where that source comes in in the viewer. When you trim a source, you should see the exact in-point that you have set in the viewer. All of this should happen while you are dragging the mouse so that you get instant feedback on your editing decisions.
1 comment:
I hate having to say this, but
"I told you so." or at least, "I told Ed so". Over a year ago, I told him that a two timelines were a recipe for disaster, and a simple timeline is a Bad Idea. First because it wastes precious development efforts, creates additional bugs (it WILL), and then because the so-called "advanced" timeline is not "advanced", it's just "not crippled". There's nothing difficult to grasp about it, and I've seen novice video editors use such timelines a lot, without problems.
Vegas Video is an example of an advanced timeline, and without prior experience, I mastered it in about five minutes of playing around with it.
Just focus on the advanced timeline and deprecate the simple one. Easier for the devs, and better for the users (both in the short and long run). And your users don't get to be considered as if they were not smart enough to use a proper timeline (you know, something that proportionally reflects the time).
Post a Comment