# Compatibilité

Chaque application ci-dessous indique sa version essayée, la commande qui l'a lancée et ce qui n'a pas été essayé. Les exécutions ont été rejouées sous Debian 13, avec les paquets de la distribution. Cette page s'adresse à qui veut savoir si sa version et sa façon de la lancer sont couvertes.

- [GIMP](#gimp) 3.0.4, mode `tcp` : deux scripts et une erreur renvoyée comme prévu.
- [Krita](#krita) 5.2.9, mode `tcp` : de même, et l'exemple du guide.
- [Blender](#blender) 4.3.2, mode `tcp` : de même, avec un rendu ; le premier a duré environ 30 s.
- [Inkscape](#inkscape) 1.4, mode `cli` : un script et une erreur comme prévu, et une capture PNG.
- [LibreOffice](#libreoffice) 25.2.3.2, mode `uno` : comme GIMP, dans Calc ; la version est restée `unknown`.

Dans chaque exécution, le Hub était l'exécutable 0.1.0, les ponts étaient les fichiers du paquet `.deb`, et le répertoire personnel, le jeton et le profil de l'application étaient neufs. Les paquets étaient 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 et Python 3.13.5-1. Une autre distribution, une autre construction d'une application ou une version plus récente n'ont pas été essayées.

Chaque exécution a été faite deux fois. Dans chacune, un premier script a été envoyé à l'application, un second a suivi (sauf pour Inkscape), un script qui levait `ValueError` est revenu avec `status: error` et la ligne de la trace d'erreur dans le script, et `get_state` a été lu. Les durées ci-dessous sont celles de la première exécution ; la seconde en différait d'au plus quelques centièmes de seconde, sauf mention contraire. Le guide de chaque application, lié dans sa section, donne les commandes pour démarrer le pont et la référence.

## GIMP

**GIMP 3.0.4, mode `tcp`.** Le pont tourne dans un GIMP lancé sans son interface. Sans affichage X, la même commande s'est arrêtée avec le code de sortie 1 et `Gtk-WARNING: cannot open display`, et le port 9311 ne s'est jamais ouvert. L'exécution a donc donné à GIMP un affichage X virtuel, avec le port 9311 et un chemin de jeton jetable.

```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()"
```

- Le port s'est mis à l'écoute environ 6 s après le démarrage de GIMP ; `get_state` sur `hub` a alors listé `gimp` comme connecté, version `3.0.4`, version du pont `1`.
- Un script qui a créé une image, rempli un calque et l'a exportée a renvoyé `status: ok` en 0,36 s avec `{"png": 2223}` ; le PNG faisait 128 par 128 pixels. Un second a suivi en 0,26 s et le pont est resté connecté.
- `get_state` sur `gimp` a renvoyé `{"active_image": null, "images": []}`, parce que le script avait supprimé son image.

Non essayé : démarrer le pont depuis la console Python interactive de GIMP (le chemin de menu, l'environnement qu'elle reçoit, la durée de vie du pont une fois la console fermée) ; plusieurs images ouvertes ; une sélection non vide ; l'exemple du guide tel qu'il est écrit. Une recette jouée avec un modèle se trouve sur la [page GIMP](https://libremodular.davalan.fr/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`.** L'exécution n'a pas utilisé le geste du guide, qui consiste à lancer le pont dans Scripter. Elle a démarré Krita sur un serveur X virtuel, avec une extension de démarrage d'une ligne dans un profil neuf, qui exécute le fichier du pont. Le port s'est mis à l'écoute de 10,4 à 10,7 s après le début de `xvfb-run`.

```sh
xvfb-run -a krita --nosplash
```

L'extension, `exec(open('/usr/share/libremodular-mcp/bridges/krita_bridge.py', encoding='utf-8').read())`, constituait tout son `__init__.py`.

- `get_state` sur `hub` a listé `krita` comme connecté, version `5.2.9`, version du pont `1`.
- Un script qui a créé un document de 300 par 200 a renvoyé `status: ok` en 0,96 s (1,20 s lors de la seconde exécution) ; un second a pris 0,20 s. L'exemple du guide, qui ajoute un calque `Notes`, a renvoyé `{"layers": ["Background", "Notes"]}` en 0,12 s.
- `get_state` a renvoyé le document avec son modèle de couleur `RGBA`, sa profondeur `U8` et son profil `sRGB-elle-V2-srgbtrc.icc`, et une capture PNG de 300 par 200 pixels aux droits 600.

L'encodage compte. Le Python embarqué de Krita lit les fichiers avec l'encodage de la locale sous laquelle il a été lancé : `ANSI_X3.4-1968` sous `LANG=C.UTF-8` et sous `LANG=C`, `UTF-8` sous `en_US.UTF-8` et sous `fr_FR.UTF-8`. Les commentaires du pont contiennent des caractères accentués, de sorte qu'une commande sans `encoding='utf-8'` s'est arrêtée avec `UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3` sous la locale C. Les commandes des guides précisent l'encodage.

Non essayé : Scripter ; plusieurs documents ouverts ; un document avec un groupe de calques. Une recette jouée avec un modèle se trouve sur la [page Krita](https://libremodular.davalan.fr/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`.** Le pont tourne dans un Blender démarré en mode arrière-plan, sans interface et sans affichage. La commande exécute le fichier du pont puis donne le fil principal au pont avec `serve_main_thread()` ; sans cet appel, la commande se termine et le pont avec elle.

```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']()
```

- Le port s'est mis à l'écoute 1,5 s après le démarrage ; `get_state` sur `hub` a listé `blender` comme connecté, version `4.3.2`, version du pont `1`.
- Un script qui a construit un cube et l'a rendu en 128 par 128 pixels a renvoyé `status: ok` avec `{"engine": "BLENDER_EEVEE_NEXT", "png": 10091}` ; le PNG faisait 128 par 128 pixels. Le même script, envoyé une seconde fois, a pris 0,12 s.
- Le premier rendu dans un profil neuf a pris 30,5 s, et 31,2 s lors de la seconde exécution, avec le délai du Hub porté à 120 s. Avec le délai par défaut de 30 s, cinq profils neufs ont donné quatre `ok` en 30,1 à 30,7 s et un `timeout` à 30,0 s, après lequel l'appel suivant a reçu `busy` jusqu'à la fin du rendu. La lenteur du premier rendu n'a pas été étudiée. Augmentez `default_timeout_s` dans la section `[hub]` de `config.toml`, ou faites un rendu à la main avant qu'un modèle n'en fasse un.
- `get_state` sur `blender` a renvoyé la scène, ses objets, la plage d'images d'animation `1` à `250`, le moteur de rendu et les objets sélectionnés.

Une exécution antérieure, consignée dans le [journal](https://libremodular.davalan.fr/journal/index.md) (en anglais), a trouvé un blocage de `bpy.ops.render.render` appelé depuis le fil d'exécution propre du pont dans 1 essai sur 23, et aucun dans 11 essais avec `serve_main_thread()`. Cette exécution n'a pas été rejouée ici.

Non essayé : démarrer le pont depuis la console de l'espace de travail Scripting d'un Blender ouvert ; un vrai écran ; des opérateurs de Blender autres que l'ajout d'un cube et le rendu ; plusieurs scènes. Une recette jouée avec un modèle se trouve sur la [page Blender](https://libremodular.davalan.fr/fr/applications/blender/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/blender.md).

## Inkscape

**Inkscape 1.4, mode `cli`.** Il n'y a pas de pont : le Hub lance un processus Python par script, avec `/usr/bin/python3` et les extensions de `/usr/share/inkscape/extensions`, et exécute `inkscape` une fois pour exporter une capture. La seule commande est l'entrée de configuration :

```toml
[apps.inkscape]
enabled = true
```

- `get_state` sur `hub` a listé `inkscape` comme connecté, version `1.4`, en mode `cli`.
- Un script qui a ajouté un calque `Notes` et un rectangle a renvoyé `{"layers": ["Layer 1", "Notes"]}` en 0,16 s.
- `get_state` a renvoyé `element_count` valant 4, une largeur de `210mm`, une hauteur de `297mm` et les deux calques, et une capture PNG de 794 par 1 123 pixels aux droits 600.

Non essayé : `OMP_NUM_THREADS` seul, sans `OPENBLAS_NUM_THREADS` (le module règle les deux) ; un document plus grand ; une fenêtre Inkscape ouverte en même temps. Une recette jouée avec un modèle se trouve sur la [page Inkscape](https://libremodular.davalan.fr/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`.** Un lanceur démarre LibreOffice avec sa fenêtre, puis le pont. L'exécution a utilisé un serveur X virtuel et réglé dans `config.toml` le port UNO sur 2102 et le port du pont sur 9314.

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

- Le lanceur est revenu en 0,01 s, et 0,1 s plus tard les trois cibles `libreoffice-writer`, `libreoffice-calc` et `libreoffice-impress` étaient connectées, avec `app_version` valant `unknown`. Le guide l'explique : quand le pont démarre avant que LibreOffice se mette à l'écoute, le Hub garde `unknown`, la version de sa connexion actuelle, jusqu'à ce qu'il se reconnecte. La version est restée `unknown` pendant toute l'exécution. Dans la [recette](https://libremodular.davalan.fr/fr/applications/libreoffice/index.md), le Hub a été démarré après que LibreOffice s'est mis à l'écoute, 1,3 s après le lanceur, et `get_state` a donné `25.2.3.2`. Une sonde UNO directe a lu `25.2.3.2`.
- Sans document ouvert, le script de l'exemple du README a reçu `doc = None`, a créé un document Calc et y a écrit `A1` et `B2`. Il a renvoyé `{"a1": 42.0, "b2": "hello", "sheet": "Sheet1"}` en 1,50 s ; relancé, en 7 ms.
- `get_state` sur `libreoffice-calc` a renvoyé la feuille et le document `Untitled 1` de la famille `calc`, et une capture PNG de 828 par 1 170 pixels aux droits 600.

Seule la cible Calc a été pilotée lors de cette exécution. Les deux tests du dépôt qui pilotent un vrai LibreOffice par le pont, `cargo test --locked --test libreoffice_real -- --ignored --nocapture`, ont réussi en 6,2 s. La version 24.2.7.2, issue des paquets d'Ubuntu 24.04, a été essayée plus tôt, comme le consigne le [journal](https://libremodular.davalan.fr/journal/index.md) (en anglais) ; elle n'a pas été rejouée ici.

Non essayé : une vraie session de bureau ; le PNG d'un document de plusieurs feuilles ou pages ; le document courant quand le focus est sur une autre fenêtre ; un démarrage à froid plus lent que 5 s. Une recette jouée avec un modèle se trouve sur la [page LibreOffice](https://libremodular.davalan.fr/fr/applications/libreoffice/index.md). [Guide](https://github.com/RonanDavalan/LibreModular-MCP/blob/main/docs/modules/libreoffice.md).