Skip to content

Implement DBus support with the Glib built in DBus interface.

Tavmjong Bah requested to merge Tavmjong/inkscape:native-dbus-support into master

This implements very trivially, access via DBus to Gio::Actions. It turns out that App level and Win level actions are automatically exported at /org/inkscape/Inkscape and /org/inkscape/Inkscape/window/# where '#' is the window number (starts counting at one) if the Gio::APPLICATION_NON_UNIQUE flag is not used (if the flag is used, the actions are still exported but are only available via a non-predictable numeric address). I exported the Doc level actions at /org/inkscape/Inkscape/document/# where '#' matches the window number (it is possible that the same document can be accessed multiple ways if it is opened in multiple windows, this doesn't seem to cause any problems.)

A simple test python script is attached. (Draw a few objects and then run script.) dbus_test.py Updated: dbus_test.py

The elephant in the room is that for all this to work the Gio::APPLICATION_NON_UNIQUE flag must be removed. This causes problems with trying to run Inkscape in headless mode (as in running "ninja check") while there is an open Inkscape window as the headless instance of Inkscape will merge itself with other Inkscape instance. In the case of running "ninja check" around 100 windows will be opened!

This scenario is prevented by using the flag Gio::APPLICATION_CAN_OVERRIDE_APP_ID. This allows a different app id to be use, preventing the merging of the a new Inkscape instance with an already running instance.

A custom app id can be set by the user via the command line argument --gapplication-app-id. This didn't work before as we were using Gio::Actions to handle a few of the command line arguments which required the app to be "registered" to make the actions available for use. The app id cannot be changed once the app is registered. I changed handling of the few command line arguments that used Gio::Actions in the command line parsing function to not use them and moved the app registration to a later point. Now --gapplication-app-id works. I also added --inkscape-app-tag and the environment variable INKSCAPE_APP_ID_TAG. When either is set the app id will be extended with the supplied tag: org.inkscape.Inkscape becomes org.inkscape.Inkscape.TAG.

To make it easier for users who use the command line while having another Inkscape instance open, when Inkscape detects that an instance of Inkscape is running with out the GUI, it will generate a custom app_id of the form org.inkscape.Inkscape.p###### where ###### is the process ID number.

A few Inkscape extensions open up new instance of Inkscape. It may be necessary to modify the python script that opens these (command.py) to use a custom app id. The app id can be set by os.environ['INKSCAPE_APP_ID_TAG'] = "ext"

Notes:

  1. With a custom app id, the different Inkscape instances will appear on the DBus with different paths.
  2. Using custom app ids allows one to run two different development versions of Inkscape at the same time (something that can't be done easily without the Gio::APPLICATION_CAN_OVERRIDE_APP_ID or the Gio::APPLICATION_NON_UNIQUE flags).
  3. When run locally, "ninja check" uses the Gtk::Application (rather than Gio::Application) unless the environment variable DISPLAY is unset and the X11 back-end is used.

A side benefit of having all GUI instances of Inkscape running at the same time is that drag-and-drop between Inkscape windows should be more reliable and race conditions when changing the preferences file should be avoided.

Reference of previous issue: #178 (closed)

Edited by Tavmjong Bah

Merge request reports