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 3.0.4, mode tcp : deux scripts et une erreur renvoyée comme prévu.
• Krita 5.2.9, mode tcp : de même, et l’exemple du guide.
• Blender 4.3.2, mode tcp : de même, avec un rendu ; le premier a duré environ 30 s.
• Inkscape 1.4, mode cli : un script et une erreur comme prévu, et une capture PNG.
• 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.

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

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.

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

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.

blender --background --python boot.py

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 (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. Guide.

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 :

[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. Guide.

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.

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, 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 (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. Guide.

SuiteVersions →