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
For the UI part, the work maybe more experimental.
What for GSoC is possible, I think, is:
1. 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
2. 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
Cheers from a fellow GSoC2008 aspirant,
thanks for sharing ideas!