OK, thanks. I think I'll avoid trying to mix the DBus usage with the current extensions system at the moment, for that reason. I'm currently looking at why the verb-execution doesn't work in headless (non-GUI) mode, and it turns out that verbs and selections are tightly-bound to the UI classes (Inkscape::UI::View::View and SPDesktop). This seems unfortunate - I was hoping that those actions that only need to operate on SPDocument instances (with Inkscape::Selection objects) might be decoupled somewhat from the GUI. This appears not to be the case, meaning that my objective of automating Inkscape functionality without a GUI might be harder than I first thought. The current headless operations (e.g. exporting PNG, PDF, query dimensions etc) are all specially hard-coded in main.cpp. Worse, the GUI functionality (upon which the verb actions depend) is all wrapped up in a giant concrete class called SPDesktop, rather than an interface class with a separate implementation. Running verbs and selection operations without a GUI would therefore seem to require the following:

- Changing the action verbs to require some new interface class rather than SPDesktop, which SPDesktop implements. The actions that do genuinely require the full GUI functionality could cast to SPDesktop and return an error (or silently fail, which seems to be the existing policy if null pointers are provided) if a full SPDesktop is not available.
- Writing of a GUI-less implementation of the new interface class which is passed to the actions
- Doing a similar thing for Inkscape::Selection (so that it doesn't require a full working SPDesktop in the constructor, and will behave nicely in the non-GUI case when one is not available). This looks slightly more straightforward, as the desktop is only used for layer-based information in the Selection class methods, as far as I can see.

There may well be good reasons for the current design where all the UI classes are required to perform any actions on an SVG document - please let me know if this is the case! However, if you think it would be acceptable for me to attempt some changes along these lines, so that actions operate on a document model where possible, and only request a GUI interface when absolutely necessary (e.g. when a dialog box needs to be shown to get parameters from the user), I think it would be a worthwhile change to those wanting to script Inkscape from the command line. I appreciate that this is probably not one of the original goals of Inkscape - however, it appears to be the best freely available software for performing certain vector graphics operations, and the current situation of requiring a GUI for anything other than the simplest format conversion operations seems to be a shame!

On 26 June 2013 16:29, Martin Owens <doctormo@gmail.com> wrote:
NP, see below.

On Wed, 2013-06-26 at 15:55 +0100, Eric Greveson wrote:
> I understand that DBus is asynchronous (which is great), but the
> existing extensions aren't! My point is that if you decide to make a
> DBus call half-way through an effect script which also modifies the
> document XML in the traditional inkex.Effect way.

Yeah. If you're going to do a dbus extension, don't actually put it in
as an extension (inx file) until the extensions-system has been told how
to deal with dbus based scripts. Otherwise you may end up with the
document getting told two different things.

Idea: Perhaps we could develop a similar module to inkey but for the
dbus side of it too. More data is needed from experimenters to see if
this is worth spending time on.