Compatibility

Each application below lists the version it was tried with, the command that started it and what was not tried. Runs were replayed on Debian 13, with the distribution’s packages. It is for anyone who wants to know whether their version and way of starting it are covered.

• GIMP 3.0.4, mode tcp: two scripts and an error returned as expected.
• Krita 5.2.9, mode tcp: the same, and the example of the guide.
• Blender 4.3.2, mode tcp: the same, with a render; the first one took about 30 s.
• Inkscape 1.4, mode cli: one script and an error as expected, and a PNG capture.
• LibreOffice 25.2.3.2, mode uno: the same as GIMP, in Calc; the version stayed unknown.

In every run the Hub was the 0.1.0 executable, the bridges were the files of the .deb package, and the home directory, the token and the profile of the application were new. The packages were GIMP 3.0.4-3+deb13u11, Krita 1:5.2.9+dfsg-1+deb13u1, Blender 4.3.2+dfsg-2, Inkscape 1.4-6, LibreOffice 4:25.2.3-2+deb13u8 and Python 3.13.5-1. Another distribution, another build of an application or a newer version was not tried.

Each run was made twice. In each, a first script was sent to the application, a second one followed (except for Inkscape), a script that raised ValueError came back with status: error and the line of the traceback in the script, and get_state was read. Durations below are those of the first run; the second differed by up to a few hundredths of a second, except where said. The guide of each application, linked in its section, gives the commands to start the bridge and the reference.

GIMP

GIMP 3.0.4, mode tcp. The bridge runs in a GIMP started without its interface. Without an X display, the same command stopped with exit code 1 and Gtk-WARNING: cannot open display, and port 9311 never opened. The run therefore gave GIMP a virtual X server; the port was 9311 and the token path a throwaway one.

LIBREMODULAR_BRIDGE_PORT=9301 \
LIBREMODULAR_TOKEN_PATH=$HOME/.config/libremodular-mcp/token \
gimp-3.0 --new-instance --no-data --no-fonts --no-interface --batch-interpreter python-fu-eval \
  -b "exec(open('/usr/share/libremodular-mcp/bridges/gimp_bridge.py', encoding='utf-8').read()); serve_main_thread()"

• The port listened about 6 s after the start of GIMP; get_state on hub then listed gimp as connected, version 3.0.4, bridge version 1.
• A script that created an image, filled a layer and exported it returned status: ok in 0.36 s with {"png": 2223}; the PNG was 128 by 128 pixels. A second one followed in 0.26 s and the bridge stayed connected.
• get_state on gimp returned {"active_image": null, "images": []}, because the script deleted its image.

Not tried: starting the bridge from the interactive Python console of GIMP (the menu path, the environment it receives, how long the bridge lives once the console is closed); several images open; a selection that is not empty; the example of the guide as written. A recipe played with a model is on the GIMP page. Guide.

Krita

Krita 5.2.9, mode tcp. The run did not use the gesture of the guide, which is to run the bridge in Scripter. It started Krita on a virtual X server with a one-line startup extension in a new profile, that runs the bridge file. The port listened 10.4 to 10.7 s after the start of xvfb-run.

xvfb-run -a krita --nosplash

The extension, exec(open('/usr/share/libremodular-mcp/bridges/krita_bridge.py', encoding='utf-8').read()), was the whole of its __init__.py.

• get_state on hub listed krita as connected, version 5.2.9, bridge version 1.
• A script that created a 300 by 200 document returned status: ok in 0.96 s (1.20 s in the second run); a second one took 0.20 s. The example of the guide, which adds a Notes layer, returned {"layers": ["Background", "Notes"]} in 0.12 s.
• get_state returned the document with its color model RGBA, depth U8 and profile sRGB-elle-V2-srgbtrc.icc, and a PNG capture of 300 by 200 pixels in mode 600.

The encoding matters. Krita’s embedded Python reads files with the encoding of the locale it was started under: ANSI_X3.4-1968 under LANG=C.UTF-8 and under LANG=C, UTF-8 under en_US.UTF-8 and fr_FR.UTF-8. The comments of the bridge hold accented characters, so a command without encoding='utf-8' stopped with UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3 under the C locale. The commands of the guides name the encoding.

Not tried: Scripter; several documents open; a document with a layer group. A recipe played with a model is on the Krita page. Guide.

Blender

Blender 4.3.2, mode tcp. The bridge runs in a Blender started in the background, without an interface and without a display. The command runs the bridge file and then hands the main thread to the bridge with serve_main_thread(); without that call, the command ends and the bridge ends with it.

blender --background --python boot.py

import runpy
ns = runpy.run_path('/usr/share/libremodular-mcp/bridges/blender_bridge.py')
ns['serve_main_thread']()

• The port listened 1.5 s after the start; get_state on hub listed blender as connected, version 4.3.2, bridge version 1.
• A script that built a cube and rendered it at 128 by 128 pixels returned status: ok with {"engine": "BLENDER_EEVEE_NEXT", "png": 10091}; the PNG was 128 by 128 pixels. The same script sent a second time took 0.12 s.
• The first render in a new profile took 30.5 s, and 31.2 s in the second run, with the delay of the Hub raised to 120 s. With the default delay of 30 s, five new profiles gave four ok in 30.1 to 30.7 s and one timeout at 30.0 s, after which the next call got busy until the render ended. Why the first render is slow was not investigated. Raise default_timeout_s in the [hub] section of config.toml, or render once by hand before a model does.
• get_state on blender returned the scene, its objects, the frame range 1 to 250, the render engine and the selected objects.

An earlier run, recorded in the journal, found a hang of bpy.ops.render.render called from the bridge’s own thread in 1 of 23 attempts, and none in 11 attempts with serve_main_thread(). That run was not replayed here.

Not tried: starting the bridge from the console of the Scripting workspace of an open Blender; a real screen; operators other than adding a cube and rendering; several scenes. A recipe played with a model is on the Blender page. Guide.

Inkscape

Inkscape 1.4, mode cli. There is no bridge: the Hub starts one Python process per script, with /usr/bin/python3 and the extensions in /usr/share/inkscape/extensions, and runs inkscape once to export a capture. The only command is the configuration entry:

[apps.inkscape]
enabled = true

• get_state on hub listed inkscape as connected, version 1.4, in mode cli.
• A script that added a layer Notes and a rectangle returned {"layers": ["Layer 1", "Notes"]} in 0.16 s.
• get_state returned element_count 4, a width of 210mm, a height of 297mm and the two layers, and a PNG capture of 794 by 1123 pixels in mode 600.

Not tried: OMP_NUM_THREADS alone, without OPENBLAS_NUM_THREADS (the module sets both); a larger document; an Inkscape window open at the same time. A recipe played with a model is on the Inkscape page. Guide.

LibreOffice

LibreOffice 25.2.3.2, mode uno. One launcher starts LibreOffice with its window and then the bridge. The run used a virtual X server and set the UNO port to 2102 and the bridge port to 9314 in config.toml.

libremodular-launch libreoffice --bridge-file /usr/share/libremodular-mcp/bridges/uno_bridge.py

• The launcher returned in 0.01 s, and 0.1 s later the three targets libreoffice-writer, libreoffice-calc and libreoffice-impress were connected, with app_version at unknown. The guide explains it: when the bridge starts before LibreOffice listens, the Hub keeps unknown, the version of its current connection, until it connects again. It stayed unknown for the whole run. In the recipe the Hub was started after LibreOffice listened, 1.3 s after the launcher, and get_state gave 25.2.3.2. A direct UNO probe read 25.2.3.2.
• With no document open, the script of the README example received doc = None, created a Calc document and wrote A1 and B2. It returned {"a1": 42.0, "b2": "hello", "sheet": "Sheet1"} in 1.50 s; run again, 7 ms.
• get_state on libreoffice-calc returned the sheet and the document Untitled 1 of the family calc, and a PNG capture of 828 by 1170 pixels in mode 600.

Only the Calc target was driven in this run. The two tests of the repository that drive a real LibreOffice through the bridge, cargo test --locked --test libreoffice_real -- --ignored --nocapture, passed in 6.2 s. Version 24.2.7.2, from the Ubuntu 24.04 packages, was tried earlier, as the journal records; it was not replayed here.

Not tried: a real desktop session; the PNG of a document with several sheets or pages; which document is current when the focus is on another window; a cold start slower than 5 s. A recipe played with a model is on the LibreOffice page. Guide.

NextChangelog →