The SVG 1.1 specification allows paths to be animated via SMIL (see my Batman logo animation - scroll down a bit and don't view in Edge). All the browsers support SMIL except IE and Edge. Microsoft has stated that they will not support it and Chrome had deprecated their support until they realized that Google was actually using it to animate buttons.
CSS animations can be used to animate most of what SMIL can animate as long as what is being animated is a CSS property. In SVG 1.1, a path is described by the 'd' attribute which is not a property. SVG 2 promotes the 'd' attribute to be a presentation property which is something that can be either an attribute or a property. (I apologize for the techno-babble). I've made the first step in making 'd' a presentation property in Inkscape. In principle, this should be easy as our handling of properties and attributes is almost the same. In practice, it's turned out to be difficult due to our Live Path Effects that rely on 'd' being an attribute. There is also the requirement that we don't turn the 'd' attribute into a property haphazardly (like we do for other presentation properties) since browsers don't have support yet for 'd' as a property. So far, what we do is turn a 'd' property into an attribute internally. The plan is to turn it back into a property at file saving time. This part hasn't been implemented yet.
Why go to this trouble now? Well, the SVG 2 spec is being reviewed and any feature that doesn't have two supporting implementations will be removed. I personally would like to see path animation supported in all browsers and the only way to get it supported in Edge seems to be via CSS animations. Chrome already includes support for 'd' as a property (albeit with a slightly different non-SVG 2 compliant syntax) so with Inkscape that gives us our two implementations to keep it in the specification.
I've spent quite a bit of time the last week exploring GActions, the replacement for the depreciated GtkActions. What is an Action? It is basically a link between a GUI element, typically a button, and some internal piece of code, nominally a callback. With GtkActions, the GUI element and the action are tightly bound. If one wants to have two different ways of say, setting the alignment of text, one needs to write two different GtkActions. GActions, on the other hand, are not tied directly to GUI elements, in fact, one can trigger a GAction without having a GUI element. Thus, one needs to write the action once. One can then attach the action to a button (or a set of buttons in our text alignment case) and a drop-down menu at the same time. One can even due this via an external XML file which means one can modify the GUI without touching the code. The end result is much simpler and more flexible code.
My goal is to create a little demonstration program that duplicates all the components found in Inkscape's tool bars and menus. I'm pretty well along on this task and should have something nice to present at our Boston hackfest at the end of March.
And finally, thanks for your support!