In order to make sure we are taliking to the same thing. Let me summary the discussion so that we can go on from here.
(1) The current Node/SPObject will be replaced or encapsulated by the SVG DOM data modeling so that all extension will rely on the SVG DOM data and events only. (2) Some UI DOM might be defined to expose inkscape to the extension. For example, the current group or color or fill will be exposed as an node in the "UI" DOM. (3) A DOM-like API will be provided by the inkscape core so that the extension should wrap this API in their own langauge. (4) extension should define the UI as an action. The whole inkscape UI will be constructed in the XForm as well.
Let me try to simulate it in my purpose. (1) We need to insert some menu item and submenu into the main menu. (2) In order to monitor the change in the layer manager, we only need to add listener to the event DOMSubtreeModified for all elements whose "groupmode" is "layer". We may need to listen to DOMNodeInserted as well to check if there is any new layer is added. The DOMNodeRemoved need to be listened as well. (3) In order to intercept the load/save/print, we will register to the SVGLoad/SVGUnload. We need some extension, such as SVGSave or SVGPrint for save/print. (4) For the current selection/color/fill/font, we need to define a special DOM object "inkscape" with the follwing structure. inkscape:uiinkscape:selection<item xlink="g3344" /><item xlink="g1122" /></inkscape:selection></inkscape:ui>
In my point of view, XForm is less important compared to the SVG DOM. The extension should use their native widgets(for us. it's pygtk) to write the UI and then add it into inkscape by some kind of docking mechanism is easy and clean. Implement Xform in both inkscape and extension is good in concept. However, in practical, I doubt it worth the effort. Think about this. We need to support the Xform Core module in both inkscpae and extension. The only thing we get is to enable the interaction between two UI natively. However, similar function can be implemented much easy by using the DOM as the common data store.
Multiple UI can work on the same synchronized SVG DOM. Once the DOM is changed by any side, the other side is notified by the DOM events and do some reaction.
YC
2010/12/15 Thinker K.F. Li <thinker@...2486...>
From: Jon Cruz <jon@...18...> Subject: Re: [Inkscape-devel] Embed Python script engine Date: Tue, 14 Dec 2010 19:35:00 -0800
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.
Do you means XForms can do or Inkscape had worked like it?
Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel