Hi, it's great work! I apologize that I follow this thread late.
I have done some work about the event listener and signal trigger of inkscape editing events in another project[1].
In short, my implementation[2] is to add an child class of "Inkscape::XML::NodeObserver", and hook 5 notification method as: (thanks to Jon Cruz's hint, someday on IRC )
1 notifyChildAdded 2 notifyChildRemoved 3 notifyChildOrderChanged 4 notifyAttributeChanged 5 notifyContentChanged
Those hook can catch all editing events of SVG modification, even undo/redo operation, too.
I guess that if we added some parsing and object filter ( for example which node changes, and which attribute changes), we could make some convenient signal to trigger external scripts.
BTW, I do not attempt affect your current work in a rush, so please keeping going your own tempo. I just wan to say that if there is something I can help/contribute to, or there is some plan about this related work, please count me in :-)
hope this information helps...
sincerely, Mat.
[1]. http://code.google.com/p/inkboardng/ [2]. http://code.google.com/p/inkboardng/source/browse/trunk/inkdbus/inkdbus-impl...
On Thu, Jul 9, 2009 at 2:56 PM, Glimmer Labs <glimmer07@...400...> wrote:
First off, I forgot to mention in my first e-mail that this is a very conservative API. Most of the functions are already written and tested, and of the rest only a few will take a decent amount of coding. The others just need to call a verb or some pre-existing Inkscape function.
I tried not to put anything in this draft that I wasn't sure could be implemented.
Signals/Events:
That being said I have been thinking about signals for a while and did not put them in the first draft for two reasons. One, they complicate things a little. Having signals or asynchronous functions requires more knowledge of dbus on the client side and adds complexity. I wanted to keep the first draft simple.
Two, I'm not sure how much work it would be to add them. Sure I could add a hack in sp_document_done, but it is not enough to know there was a keyboard event, you also want to know what key was pressed (for example.) To get the data of an Inkscape event I would need to create EventListeners and register them with EventTargets and parse values and decide which to send and so on for each signal I wanted to expose.
Maybe someone who knows the event system will tell me that there is a way to expose all the Inkscape events at once without having to do a lot of coding for each separate signal I want to send, but I doubt it.
I'll keep looking into it though, it's definitely a possibility and I'm sure it will get done at some point if there is demand for it. Perhaps I'll create a "Proposed" interface to act as a sort of API wishlist.
Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel