On 2010-12-14 11:15, Yu-Chung Wang wrote:
2010/12/14 Jasper van de Gronde<th.v.d.gronde@...528...>:
... Also, some mention was made of things like a time-line, and I agree that it might be hard to make Inkscape "understand" that when it has no concept of a time-line. I would like to argue though that perhaps it might be better to first make sure Inkscape DOES have such a concept and then thinking of a UI. Or, alternatively, if you want to go really overboard with UI changes, I could imagine Inkscape separating the UI from rendering and such. In that case you could conceivably build a completely different UI on top of the same core technology.
In order to make inkscape understand what is timeline, there are two approaches.
(1) Add the timeline concept into the inkscape directly. (2) Add the time line concept in the extension. The time line is constructed by using the function available in the inkscape.
Currently, I take the second appraoch. The time line is exactly implemented as a sub layer. Any layer in the inkscape can have multiple sub layer. The timeline UI ensure that only one of them are visible. For the inkscape itself, it does not need to know the timeline at all. ...
To give an example why having a high level abstraction layer for extensions(!) will ultimately make it easier to write and maintain extensions, consider shortcuts. A few months back I changed tooltips for "Actions" to show the associated keyboard shortcut (if any). The main problem in doing so was that unfortunately Actions aren't used (consistently) everywhere yet to expose functionality, if they had been it probably would have taken me only half the time to make this change (if not less). Imagine that extensions would have to take care of such things on their own...
Now imagine something more serious than playing with tooltips, consider changing toolkits, changing from using menus and toolbars to using ribbons (no please, but still), or even just a different kind of toolbar. Or what about changing how we handle windows like the fill&stroke and alignment dialogs. If extensions have to be aware of how we do such things and take care of it themselves then we are bound to run into a maintainability nightmare sooner or later (probably sooner), not to mention inconsistencies and such. It would also dramatically raise the bar for people to contribute extensions, as they would necessarily have to know how to program a GUI.
So instead of letting an extension put an icon/button in a certain toolbar/menu we should let extensions create actions for example. Obviously this still needs a lot of work, but in the end it should save us a lot of headaches. Note that embedding the Python interpreter is not necessarily a problem, it's just that it might be better to let the exposed API focus on providing a high level abstraction.
In the (very) long run I /could/ imagine exposing more low-level functionality, but more in an attempt to move part of Inkscape's code to Python (or some other higher level language) than to allow more advanced "extensions". I could potentially see animation support coming to Inkscape through this route, but preferrably after we have a more advanced extension system, to avoid the aforementioned problems.
BTW, in case we misunderstood each other, I thought you were talking about a timeline for supporting animation or something like that (a timeline as part of the UI). I would not exactly advocate implementing animation support as just another "extension". An extension to draw timelines shouldn't be a big problem in any extension system, and especially easy in one that provides a high-level abstraction layer (DOM, plus some extras perhaps), as you then don't need to worry about Inkscape's internals.