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.h

On Thu, Jul 9, 2009 at 2:56 PM, Glimmer Labs <glimmer07@gmail.com> 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