Kompatibilität

Jede Anwendung unten nennt die Version, mit der sie erprobt wurde, den Befehl, der sie gestartet hat, und was nicht ausprobiert wurde. Die Läufe wurden unter Debian 13 mit den Paketen der Distribution wiederholt. Die Seite richtet sich an alle, die wissen wollen, ob ihre Version und ihre Startweise abgedeckt sind.

• GIMP 3.0.4, Modus tcp: zwei Skripte und ein Fehler, wie erwartet zurückgegeben.
• Krita 5.2.9, Modus tcp: dasselbe und das Beispiel des Leitfadens.
• Blender 4.3.2, Modus tcp: dasselbe, mit einem gerenderten Bild; das erste Rendern dauerte etwa 30 s.
• Inkscape 1.4, Modus cli: ein Skript und ein Fehler wie erwartet sowie eine PNG-Aufnahme.
• LibreOffice 25.2.3.2, Modus uno: dasselbe wie bei GIMP, in Calc; die Version blieb unknown.

In jedem Lauf war der Hub die ausführbare Datei 0.1.0, die Brücken waren die Dateien des .deb-Pakets, und das Home-Verzeichnis, das Token und das Profil der Anwendung waren neu. Die Pakete waren 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 und Python 3.13.5-1. Eine andere Distribution, ein anderer Build einer Anwendung oder eine neuere Version wurden nicht ausprobiert.

Jeder Lauf wurde zweimal gemacht. In jedem wurde der Anwendung ein erstes Skript gesendet, ein zweites folgte (außer bei Inkscape), ein Skript, das ValueError auslöste, kam mit status: error und der Zeile der Fehlerspur im Skript zurück, und get_state wurde gelesen. Die Dauern unten stammen aus dem ersten Lauf; der zweite wich um bis zu wenige Hundertstelsekunden ab, außer wo es anders steht. Der Leitfaden jeder Anwendung, in ihrem Abschnitt verlinkt, nennt die Befehle zum Starten der Brücke und die Referenz.

GIMP

GIMP 3.0.4, Modus tcp. Die Brücke läuft in einem GIMP, das ohne Benutzeroberfläche gestartet wurde. Ohne X-Display endete derselbe Befehl mit Exit-Code 1 und Gtk-WARNING: cannot open display, und der Port 9311 öffnete sich nie. Der Lauf gab GIMP deshalb ein virtuelles X-Display; der Port war 9311, und der Token-Pfad war ein Wegwerfpfad.

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

• Der Port lauschte etwa 6 s nach dem Start von GIMP; get_state für hub listete danach gimp als verbunden auf, Version 3.0.4, Brückenversion 1.
• Ein Skript, das ein Bild anlegte, eine Ebene füllte und es exportierte, gab status: ok in 0,36 s mit {"png": 2223} zurück; das PNG war 128 × 128 Pixel groß. Ein zweites folgte in 0,26 s, und die Brücke blieb verbunden.
• get_state für gimp gab {"active_image": null, "images": []} zurück, weil das Skript sein Bild gelöscht hatte.

Nicht ausprobiert: die Brücke aus der interaktiven Python-Konsole von GIMP starten (der Menüweg, die Umgebung, die sie erhält, wie lange die Brücke nach dem Schließen der Konsole lebt); mehrere geöffnete Bilder; eine Auswahl, die nicht leer ist; das Beispiel des Leitfadens wie geschrieben. Ein mit einem Modell gespieltes Rezept steht auf der GIMP-Seite. Leitfaden.

Krita

Krita 5.2.9, Modus tcp. Der Lauf nutzte nicht das Vorgehen des Leitfadens, die Brücke in Scripter auszuführen. Er startete Krita auf einem virtuellen X-Display mit einer einzeiligen Startup-Erweiterung in einem neuen Profil, die die Brückendatei ausführt. Der Port lauschte 10,4 bis 10,7 s nach dem Start von xvfb-run.

xvfb-run -a krita --nosplash

Die Erweiterung, exec(open('/usr/share/libremodular-mcp/bridges/krita_bridge.py', encoding='utf-8').read()), war der gesamte Inhalt ihrer __init__.py.

• get_state für hub listete krita als verbunden auf, Version 5.2.9, Brückenversion 1.
• Ein Skript, das ein Dokument von 300 × 200 anlegte, gab status: ok in 0,96 s zurück (1,20 s im zweiten Lauf); ein zweites brauchte 0,20 s. Das Beispiel des Leitfadens, das eine Ebene Notes hinzufügt, gab {"layers": ["Background", "Notes"]} in 0,12 s zurück.
• get_state gab das Dokument mit seinem Farbmodell RGBA, der Tiefe U8 und dem Profil sRGB-elle-V2-srgbtrc.icc zurück sowie eine PNG-Aufnahme von 300 × 200 Pixeln im Modus 600.

Die Kodierung ist wichtig. Das eingebettete Python von Krita liest Dateien mit der Kodierung des Locales, unter dem es gestartet wurde: ANSI_X3.4-1968 unter LANG=C.UTF-8 und unter LANG=C, UTF-8 unter en_US.UTF-8 und fr_FR.UTF-8. Die Kommentare der Brücke enthalten Zeichen mit Akzent, daher brach ein Befehl ohne encoding='utf-8' unter dem Locale C mit UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3 ab. Die Befehle der Leitfäden nennen die Kodierung.

Nicht ausprobiert: Scripter; mehrere geöffnete Dokumente; ein Dokument mit einer Ebenengruppe. Ein mit einem Modell gespieltes Rezept steht auf der Krita-Seite. Leitfaden.

Blender

Blender 4.3.2, Modus tcp. Die Brücke läuft in einem Blender, das im Hintergrundmodus ohne Benutzeroberfläche und ohne Display gestartet wurde. Der Befehl führt die Brückendatei aus und übergibt der Brücke dann mit serve_main_thread() den Hauptthread; ohne diesen Aufruf endet der Befehl, und die Brücke endet mit ihm.

blender --background --python boot.py

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

• Der Port lauschte 1,5 s nach dem Start; get_state für hub listete blender als verbunden auf, Version 4.3.2, Brückenversion 1.
• Ein Skript, das einen Würfel baute und mit 128 × 128 Pixeln rendern ließ, gab status: ok mit {"engine": "BLENDER_EEVEE_NEXT", "png": 10091} zurück; das PNG war 128 × 128 Pixel groß. Dasselbe Skript, ein zweites Mal gesendet, brauchte 0,12 s.
• Das erste Rendern in einem neuen Profil dauerte 30,5 s, im zweiten Lauf 31,2 s, bei auf 120 s erhöhter Frist des Hubs. Mit der Standardfrist von 30 s ergaben fünf neue Profile viermal ok in 30,1 bis 30,7 s und einmal timeout bei 30,0 s, wonach der nächste Aufruf busy erhielt, bis das Rendern endete. Warum das erste Rendern langsam ist, wurde nicht untersucht. Erhöhen Sie default_timeout_s im Abschnitt [hub] von config.toml, oder rendern Sie einmal von Hand, bevor ein Modell es tut.
• get_state für blender gab die Szene, ihre Objekte, den Bereich der Einzelbilder 1 bis 250, die Render-Engine und die ausgewählten Objekte zurück.

Ein früherer Lauf, im Journal (auf Englisch) festgehalten, fand bei 1 von 23 Versuchen ein Hängen von bpy.ops.render.render, aufgerufen aus dem eigenen Thread der Brücke, und keines bei 11 Versuchen mit serve_main_thread(). Dieser Lauf wurde hier nicht wiederholt.

Nicht ausprobiert: die Brücke aus der Konsole des Arbeitsbereichs Scripting eines geöffneten Blender starten; ein echter Bildschirm; andere Operatoren als das Hinzufügen eines Würfels und das Rendern; mehrere Szenen. Ein mit einem Modell gespieltes Rezept steht auf der Blender-Seite. Leitfaden.

Inkscape

Inkscape 1.4, Modus cli. Es gibt keine Brücke: Der Hub startet pro Skript einen Python-Prozess, mit /usr/bin/python3 und den Erweiterungen in /usr/share/inkscape/extensions, und führt inkscape einmal aus, um eine Aufnahme zu exportieren. Der einzige Befehl ist der Konfigurationseintrag:

[apps.inkscape]
enabled = true

• get_state für hub listete inkscape als verbunden auf, Version 1.4, im Modus cli.
• Ein Skript, das eine Ebene Notes und ein Rechteck hinzufügte, gab {"layers": ["Layer 1", "Notes"]} in 0,16 s zurück.
• get_state gab element_count 4, eine Breite von 210mm, eine Höhe von 297mm und die beiden Ebenen zurück sowie eine PNG-Aufnahme von 794 × 1 123 Pixeln im Modus 600.

Nicht ausprobiert: OMP_NUM_THREADS allein, ohne OPENBLAS_NUM_THREADS (das Modul setzt beide); ein größeres Dokument; ein gleichzeitig geöffnetes Inkscape-Fenster. Ein mit einem Modell gespieltes Rezept steht auf der Inkscape-Seite. Leitfaden.

LibreOffice

LibreOffice 25.2.3.2, Modus uno. Ein Starter startet LibreOffice mit seinem Fenster und danach die Brücke. Der Lauf nutzte ein virtuelles X-Display und setzte in config.toml den UNO-Port auf 2102 und den Brückenport auf 9314.

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

• Der Starter kehrte nach 0,01 s zurück, und 0,1 s später waren die drei Ziele libreoffice-writer, libreoffice-calc und libreoffice-impress verbunden, mit app_version bei unknown. Der Leitfaden erklärt es: Startet die Brücke, bevor LibreOffice lauscht, behält der Hub unknown, die Version seiner aktuellen Verbindung, bis er sich erneut verbindet. Es blieb im gesamten Lauf unknown. Im Rezept wurde der Hub gestartet, nachdem LibreOffice lauschte, 1,3 s nach dem Starter, und get_state gab 25.2.3.2. Eine direkte UNO-Probe las 25.2.3.2.
• Ohne geöffnetes Dokument erhielt das Skript des README-Beispiels doc = None, legte ein Calc-Dokument an und schrieb A1 und B2. Es gab {"a1": 42.0, "b2": "hello", "sheet": "Sheet1"} in 1,50 s zurück; erneut ausgeführt, in 7 ms.
• get_state für libreoffice-calc gab das Tabellenblatt und das Dokument Untitled 1 der Familie calc zurück sowie eine PNG-Aufnahme von 828 × 1 170 Pixeln im Modus 600.

In diesem Lauf wurde nur das Ziel Calc gesteuert. Die beiden Tests des Repositorys, die ein echtes LibreOffice über die Brücke steuern, cargo test --locked --test libreoffice_real -- --ignored --nocapture, bestanden in 6,2 s. Die Version 24.2.7.2 aus den Paketen von Ubuntu 24.04 wurde früher erprobt, wie das Journal (auf Englisch) festhält; sie wurde hier nicht wiederholt.

Nicht ausprobiert: eine echte Desktop-Sitzung; das PNG eines Dokuments mit mehreren Tabellenblättern oder Seiten; welches Dokument das aktuelle ist, wenn der Fokus auf einem anderen Fenster liegt; ein Kaltstart, der langsamer ist als 5 s. Ein mit einem Modell gespieltes Rezept steht auf der LibreOffice-Seite. Leitfaden.

WeiterVersionen →