# 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](#gimp) 3.0.4, mode `tcp`: two scripts and an error returned as expected.
- [Krita](#krita) 5.2.9, mode `tcp`: the same, and the example of the guide.
- [Blender](#blender) 4.3.2, mode `tcp`: the same, with a render; the first one took about 30 s.
- [Inkscape](#inkscape) 1.4, mode `cli`: one script and an error as expected, and a PNG capture.
- [LibreOffice](#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.

```sh
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](https://libremodular.davalan.fr/applications/gimp/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/gimp.md).

## 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`.

```sh
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](https://libremodular.davalan.fr/applications/krita/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/krita.md).

## 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.

```sh
blender --background --python boot.py
```

```python
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](https://libremodular.davalan.fr/journal/index.md), 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](https://libremodular.davalan.fr/applications/blender/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/blender.md).

## 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:

```toml
[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](https://libremodular.davalan.fr/applications/inkscape/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/inkscape.md).

## 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`.

```sh
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](https://libremodular.davalan.fr/applications/libreoffice/index.md) 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](https://libremodular.davalan.fr/journal/index.md) 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](https://libremodular.davalan.fr/applications/libreoffice/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/libreoffice.md).