I committed changes which implement resizing of clips in the advanced timeline this morning. So there's a pitivi first. I'm tinkering with support for "edge" snapping, which is crucial for usability. Edward is still working on refactoring pitivi core so that we can handle still images. I also added some cosmetic changes, because I was tired of the way things were looking. Unfortunately, the only thing giving you any clue you're resizing something, is the cursor, and that didn't come through in the screenshot.
Here's my revised todo list:
- Fix graphic bug created when advanced timeline loads from file which places clips in the wrong order.
- Layout changes, implement a toolbar
- Delete clips in advanced UI
- Split clips in advanced UI
- make Text item something we can shrink so it doesn't protrude past edge of clip at high zoom
- make edge snapping work
- Drag multiple selected objects
- Undo/Redo
- Multi-layer editing
- Still Images
In the mean time, i'm thinking about how undo/redo support should work. It's kindof a tricky problem. One hackish way to implement it would be to serialize the timeline to the intermediate format after every major undoable event (via a signal emitted from PiTiVi core or in the UI). If the user wants to undo, then we can simply reload the undo tree, as if we were loading a file. That might be a way to implement single-action undo/redo for the next release. Multiple undo/redo will have to be a little smarter: a stack of operations needs to be mantained somehow, and each operation needs to have an inverse. Undoing in this case means poping the top of the stack, and applying the inverse operation to the timeline. The trick of course, is providing the infrastructure for both maintaining this history, and reversing the changes. Part of the problem is deciding which events are actually undoable. For example, during the course of a drag in the PiTiVi timeline, a source's position will be updated potentially thousands of times. We only care about its position before and after the drag operation, and only the UI can provide this perspective.
I wish I had some kind of handbook on how to implement these big, complicated, yet crucial features.
3 comments:
Brandon,
Very cool work you and Edward are doing on Pitivi. How the heck do you pronounce that anyway... Just thinking that it might be good to post your updates to the mail list. You might get more help figuring out how to implement some of these things...just a suggestion.
Thanks for all you hard work.
Jokosher has developed its own infrastructure for undo/redo functionality. This includes:
1) a stack system
2) python decorators for wrapping functions which perform undoable actions
3) Serializing/deserializing the undo stack with XML.
4) A system for to group many actions together into one. For example if you delete multiple audio clips, it put all the delete() function calls together so what when the user presses undo, all items are restored instead of just one.
I'm sure the Jokosher way is not the only way to implement this, and it may not even be the best way, but it works great for us. And its already implemented in Python. All the application needs to provide is for each action, the function name of the opposite action.
If you need any help just ask on jokosher-devel-list@gnome.org or on #jokosher on freenode. We could probably give you some advice on how to implement this thing.
PiTiVi is pronounced as if there were no I's in the name, i.e. P.T.V.
I'd post to the mailing list, but I'm required to have a blog for SoC. I don't really feel like making two separate postings, though. Even if I just copy from one to the other it's a pain. I prefer the blog format anyways, because it lets me make corrections after the fact. I am hoping to get the blog aggregated on Planet Gnome, however.
I'll take a look at the jokosher way of doing things. But I'm kinda starting to realize that Undo/Redo are probably out-of-scope for the summer.
Post a Comment