On Wed, Mar 12, 2008 at 4:27 PM, <J.B.C.Engelen@...1578...> wrote:
If I read your intentions correctly, you should not aim to get something working :) (not fully at least).
Yes, being fully SMIL compliant at the end of the summer seems quite unrealistic. But I think "the backend" part of the implementation should be made in a general enough way to support everything in the end. For the UI part, the work maybe more experimental.
What for GSoC is possible, I think, is:
- Make Inkscape not forget svg animation attributes (basically make the SPObject thingies that are already present for svg:rect svg:path svg:g etc but then for svg:animation). Don't let the objects do anything :) because that alone would mean more than one GSoC project I think. Perhaps Inkscape already doesn't 'forget' the attributes, that'd be awesome, and then this step vanishes.
Inkscape seems to keep the attributes around already. For the experiments I posted on the wikipage, I used the XML editor to add the animation elements by hand. They're saved along the rest of the file. Animation elements are not bound to runtime objects though, so yes creating those representations is the first step (actually there is a (not compiled?) sp-animation.cpp stub in the codebase). Then animatable attributes should gain the notion of 'presentation time value', controlled by the current (stack of) animation applied to them.
- Make simple UI to edit svg animation attributes. Onion-skinning etc sound like a GSoC project of their own! Really, it depends on how much time you are going to invest, but have a look at the size of last year's gsocprojects. Probably the simplest you can come up with is already enough work! So perhaps you could pick one part of animation attributes UI and make something for that. (i.e. only make the timeline UI, with enough simplicity and complexity)
Indeed the timeline UI in itself is quite some work I guess. Maybe just implementing the motion path on-canvas helper with onion skinning simulation could be more reasonable for this period of time.
Now that I think of it, it would have helped me to have an LPE editing mockup before I started. (more precise than what I had in my head) So perhaps you should (like you already did) start gsoc with as precise a UI description as possible. (for example also, who writes to XML, what will be written to XML, which XML changes should trigger an update of which widgets, etc...
That's seem a good plan of action. I'd like to avoid proposing something that turns out to be a dead-end for future improvements (toward full SMIL compliance), So a careful analysis is definitely good. And making mockups would help getting feedback from animation-aware users.
Cheers from a fellow GSoC2008 aspirant, Johan
thanks for sharing ideas!
Cheers, Christophe