On Dec 14, 2010, at 3:48 PM, Yu-Chung Wang wrote:
Actually, we are developing a timeline animation like Flash by using the python "extension". Obviously, we see more and more functions which need to be exposed to the "extension". This is why we raise the question if we need to define a official set of interface in side the inkscape. We have binded a couple of features already. However, we hope that we can use a stable interface so that we don't need to sync with the inkscape itself in the future.
Yes, it needs to be stable... but most functionality that is common to SVG (such as base animation) is needed inside of Inkscape itself. The providing it in a consistent manner to *all* extensions, not just your custom Python binding, will bring the most end-user benefit.
For example, we are using Node/NodeObserver API extensively. If this is changed, we need to rewrite our system as well.
Yes, these are likely to change over time. The DOM API will not be, as that has already been defined by external standards bodies. Or rather it will not change for SVG 1.1 but will be different for SVG 2.0.
I can totally agree that bind function through actions is a good idea. Actually, make the whole inkscape UI can be customized via method like the menu.xml is good as well. This raise the question to adopt XUL or XForms. However, I doubt that value of XUL or XForms in the inkscape. It's a good concept, but it might not worth the effort in pratice. No matter XUL or XForms, we need to build a set of widgets to use them. Unless inkscape want to embedded gecko or webkit inside it in the long run. Use propriatary XML format to change the UI is more practical.
XUL is very very different from XForms. The latter presents some abstract data models and allows the hosting presentation to render them however it wants.
Oh, and we already are using it for our extension .inx support. Parameters are implemented via declarative functional UI, and and provide rendering 'hints' to allow inkscape to provide the more appropriate GTK widgets as needed.
For the extension, I believe that there are other more important thing than XForms or XUL. Use actions have solved most UI issues. Write Layer manager in XUL or XForms might not be so interesting for me.
There are some area which is more insteresting
- Let extension get notified when the inkscape doing some jobs, such as * Load/Save file * Print * Change document property
Yes, those are supported via the 'UI' DOM and DOM Events. And events such as the change document are already defined by XForms.
- Intercept the procedure of modifying the object. Allow extension to disable the action.
For example, protect some objects generated by the extension from deleting.
Yes, this two is completely supported via DOM Events. The order, canceling, overriding, etc. has all been worked out and refined. It does have a few shortcomings, but our current dual-tree model has even more (look to the bugs with layer renaming, etc. for examples of those problems)
http://xformsinstitute.com/essentials/browse/ch07.php#ch07-2-fm2xml
"capture" and "bubbling" are the concepts you're most likely interested in.
- Change the layout of the inkscape so that we can embedded the whole inkscape
into another application.
This actually starts to get quite tricky. Experience with XEmbed, CORBA, Bonobo, OLE, OpenDoc, etc. comes into play to help understand some of the problems.
- Expose some information to the extension. Such as, Selection, current group, current tool.
All feasible with DOM and DOM Events.