A test of the new dbus features of Inkscape 1.2.1+
This allows an Inkscape session to be controlled from a separate gui.
It supports running basic macros.
There are 3 branches of dbus actions:
Application / Window / Document
Choose an action - add a parameter if required, click run to activate the action.
Double click the action to add to the macro list.
The items in the macro list can be toggled on / off or deleted. The macro list supports drag reordering of items. You can set a number of repeats - for example you could simplify 72 times if you wanted to.
For Ubuntu 20+ everything should work.
For Windows 10+
the path to Inkscape python is assumed to be c:/program files/inkscape/bin/python.exe'
The 'Window' branch of dbus does not work. I have raised an issue on Inkscape gitlab for this.
Please note:
It does help if you have some knowledge of how the command line works.
Most of the Application dbus actions mirror the command line and its parameters.
Some of the commands act as 'flags' which are set, for example if you set export-area-page to True, then it has to be set to False again before you can use export-area-drawing set to True. As a quirk export-area which takes dimensions, once used you cannot go back to export-area-page etc. for that session.
This is a new feature of Inkscape - so be prepared for exciting thinks to happen unexpectedly.
For the windows path, it has to be the path to the 'inkscape python' installation. So for example some users might install inkscape to d:\my applications\inkscape or some other random path for example during the installation process.
99% ( a guess : ) of windows users will have obtained python using the Inkscape installer. If however sys.executable does find another python install I think it will break because it is not the Inkscape venv ?
For mac - I have no idea if it would work. However - it would be simple enough to add a 'darwin' block to gtk3_dbus_standalone.py
I just wrote this so people would know it exists - and maybe generate some interest. As noted though, the 'window' path commands do not work in Windows at the moment.
It usually returns the python interpreter which was calling the script. So that would be perfect in this case. But could also be used as a fallback.
It has been tested on macOS now. ... and it fails. The macOS Inkscape version doesn't ship with dbus while in Windows you can find the gdbus library. Seems as no dbus connection can be established - at least not with a default setup.
https://gitlab.com/inklinea/ink-dbus
Ink Dbus
A test of the new dbus features of Inkscape 1.2.1+
This allows an Inkscape session to be controlled from a separate gui.
It supports running basic macros.
There are 3 branches of dbus actions:
Application / Window / Document
Choose an action - add a parameter if required, click run to activate the action.
Double click the action to add to the macro list.
The items in the macro list can be toggled on / off or deleted. The macro list supports drag reordering of items. You can set a number of repeats - for example you could simplify 72 times if you wanted to.
For Ubuntu 20+ everything should work.
For Windows 10+
the path to Inkscape python is assumed to be c:/program files/inkscape/bin/python.exe'
The 'Window' branch of dbus does not work. I have raised an issue on Inkscape gitlab for this.
Please note:
It does help if you have some knowledge of how the command line works.
Most of the Application dbus actions mirror the command line and its parameters.
Some of the commands act as 'flags' which are set, for example if you set
export-area-page
to True, then it has to be set to False again before you can useexport-area-drawing
set to True. As a quirkexport-area
which takes dimensions, once used you cannot go back toexport-area-page
etc. for that session.This is a new feature of Inkscape - so be prepared for exciting thinks to happen unexpectedly.
.
I think you could use
sys.executable
instead?Do you have any feedback from macOS users on this extension so far?
Hi Kaallen,
For the windows path, it has to be the path to the 'inkscape python' installation. So for example some users might install inkscape to d:\my applications\inkscape or some other random path for example during the installation process.
99% ( a guess : ) of windows users will have obtained python using the Inkscape installer. If however
sys.executable
does find another python install I think it will break because it is not the Inkscape venv ?For mac - I have no idea if it would work. However - it would be simple enough to add a 'darwin' block to
gtk3_dbus_standalone.py
I just wrote this so people would know it exists - and maybe generate some interest. As noted though, the 'window' path commands do not work in Windows at the moment.
It usually returns the python interpreter which was calling the script. So that would be perfect in this case. But could also be used as a fallback.
It has been tested on macOS now. ... and it fails. The macOS Inkscape version doesn't ship with dbus while in Windows you can find the gdbus library. Seems as no dbus connection can be established - at least not with a default setup.
Many thanks - I will have a look at the
sys.executable
I could be a great solution for non standard install paths :)
Hello Kaalleen, I found that
sys.executable
returnspythonw.exe
instead ofpython.exe
I was able to add this little piece of code to the inkdbus and the selection plus extensions:
Now it all works :) Thanks
... I assume that pythonw.exe for Windows is the correct path since it is the inkscape default?
https://inkscape.gitlab.io/extensions/documentation/authors/interpreters.html
It is correct, however pythonw.exe does not correctly trigger the detached subprocess.
python.exe however does :)
Even if Inkscape is shutdown, reopened, any number of times.
The standalone GTK3 window will work correctly for the newly opened Inkscape.
Ah I see, ok.