Hi Martin,

Thanks for the suggestion. This does sound easier to implement, and should integrate nicely with the existing extensions. This approach could solve my particular problem, however, my concerns are:

1) Changes made to the document in the extension are not reflected in Inkscape, so for example, if in my extension I add a path, then attempt to select it and perform some verb on it, it won't work. Inkscape has no knowledge of the path that the extension has added until the extension terminates. Getting this to work properly would require synchronization of the documents before and after each DBus message (i.e. send the document from extension to Inkscape, get Inkscape to replace its document with the one that was sent, perform the DBus action, send the new document from Inkscape back to the extension, resume execution of the extension script). Can this synchronization be performed via DBus as well? Wouldn't it slow down the script considerably?
2) What is the status of DBus on Windows or Mac? Would the scripting improvements be available in standard installs on all operating systems?
3) If it's conditional on DBus being compiled in (which I guess answers my question 2, as DBus might not be available by default on all platforms), this would presumably result in the creation of "second-class citizen" scripts which only run in certain environments - and perhaps limit the appeal of using these features.

I can see the obvious benefits (potentially less coding for me, no Boost dependency) but the fundamental mode of operation of existing extensions (dump Inkscape document SVG, run script to modify document outside of Inkscape, re-import document) makes it difficult to integrate the mixing of existing script functionality (direct DOM changes/transforms) with verb and select operations (which operate on the Inkscape document).

Perhaps I should consider writing my Python script outside of Inkscape, and sending the commands via DBus from this external Python script, as this would seemingly solve my current problem. However, could I get this to work in non-GUI mode? How much overhead is involved (say, if I plan to do ~10000 Boolean operations on a typical SVG containing ~10000 paths)?

Eric


On 26 June 2013 14:58, Martin Owens <doctormo@...400...> wrote:
On Wed, 2013-06-26 at 13:20 +0100, Eric Greveson wrote:
> Thoughts from those who might be able to approve any future merge
> requests I make? My preference is for option c), but if a Boost
> dependency would be frowned upon for any reason, then option a) would
> be next on my list.

Option e) have an idx specify it uses dbus and pass the desktop's dbus
address and the addresses/ids of selected objects only. Disable script
if dbus support not compiled in.

Certainly what I would go for considering the advantages of not having
to care too much about the script's language. It could even be compiled
C, C++, Vala or Java. (for those that want to make things hard ;-))

Some improvements to the DBus api, good signals etc and it might be
worth quite a bit to allowing our extensions more latitude.

Martin,