Compatibilidad

Cada aplicación de abajo indica la versión con la que se probó, el comando que la inició y lo que no se probó. Las ejecuciones se repitieron en Debian 13, con los paquetes de la distribución. Es para quien quiere saber si su versión y su forma de iniciarla están cubiertas.

• GIMP 3.0.4, modo tcp: dos scripts y un error devuelto como se esperaba.
• Krita 5.2.9, modo tcp: lo mismo, y el ejemplo de la guía.
• Blender 4.3.2, modo tcp: lo mismo, con un renderizado; el primero tardó unos 30 s.
• Inkscape 1.4, modo cli: un script y un error como se esperaba, y una captura PNG.
• LibreOffice 25.2.3.2, modo uno: lo mismo que GIMP, en Calc; la versión siguió siendo unknown.

En todas las ejecuciones, el Hub fue el ejecutable 0.1.0, los puentes fueron los archivos del paquete .deb, y el directorio personal, el token y el perfil de la aplicación eran nuevos. Los paquetes fueron 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 y Python 3.13.5-1. No se probó otra distribución, otra compilación de una aplicación ni una versión más reciente.

Cada ejecución se hizo dos veces. En cada una se envió un primer script a la aplicación, le siguió un segundo (salvo en Inkscape), un script que lanzó ValueError volvió con status: error y la línea de la traza de error dentro del script, y se leyó get_state. Las duraciones de abajo son las de la primera ejecución; la segunda difirió hasta unas centésimas de segundo, salvo donde se indica. La guía de cada aplicación, enlazada en su sección, da los comandos para iniciar el puente y la referencia.

GIMP

GIMP 3.0.4, modo tcp. El puente se ejecuta en un GIMP iniciado sin su interfaz. Sin una pantalla X, el mismo comando se detuvo con el código de salida 1 y Gtk-WARNING: cannot open display, y el puerto 9311 no llegó a abrirse. Por eso la ejecución dio a GIMP una pantalla X virtual; el puerto fue el 9311 y la ruta del token, una desechable.

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

• El puerto empezó a escuchar unos 6 s después de iniciar GIMP; get_state sobre hub enumeró entonces gimp como conectado, versión 3.0.4, versión del puente 1.
• Un script que creó una imagen, rellenó una capa y la exportó devolvió status: ok en 0,36 s con {"png": 2223}; el PNG era de 128 por 128 píxeles. Le siguió un segundo en 0,26 s y el puente siguió conectado.
• get_state sobre gimp devolvió {"active_image": null, "images": []}, porque el script borró su imagen.

No se probó: iniciar el puente desde la consola interactiva de Python de GIMP (la ruta de menú, el entorno que recibe, cuánto vive el puente una vez cerrada la consola); varias imágenes abiertas; una selección que no esté vacía; el ejemplo de la guía tal como está escrito. Una receta ejecutada con un modelo está en la página de GIMP. Guía.

Krita

Krita 5.2.9, modo tcp. La ejecución no usó el gesto de la guía, que consiste en ejecutar el puente en Scripter. Inició Krita en una pantalla X virtual con una extensión de arranque de una sola línea en un perfil nuevo, que ejecuta el archivo del puente. El puerto empezó a escuchar entre 10,4 y 10,7 s después de iniciar xvfb-run.

xvfb-run -a krita --nosplash

La extensión, exec(open('/usr/share/libremodular-mcp/bridges/krita_bridge.py', encoding='utf-8').read()), era todo su __init__.py.

• get_state sobre hub enumeró krita como conectado, versión 5.2.9, versión del puente 1.
• Un script que creó un documento de 300 por 200 devolvió status: ok en 0,96 s (1,20 s en la segunda ejecución); un segundo tardó 0,20 s. El ejemplo de la guía, que añade una capa Notes, devolvió {"layers": ["Background", "Notes"]} en 0,12 s.
• get_state devolvió el documento con su modelo de color RGBA, profundidad U8 y perfil sRGB-elle-V2-srgbtrc.icc, y una captura PNG de 300 por 200 píxeles con el modo 600.

La codificación importa. El Python incorporado de Krita lee los archivos con la codificación de la configuración regional con la que se inició: ANSI_X3.4-1968 con LANG=C.UTF-8 y con LANG=C, UTF-8 con en_US.UTF-8 y fr_FR.UTF-8. Los comentarios del puente contienen caracteres con acento, así que un comando sin encoding='utf-8' se detuvo con UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3 en la configuración regional C. Los comandos de las guías nombran la codificación.

No se probó: Scripter; varios documentos abiertos; un documento con un grupo de capas. Una receta ejecutada con un modelo está en la página de Krita. Guía.

Blender

Blender 4.3.2, modo tcp. El puente se ejecuta en un Blender iniciado en segundo plano, sin interfaz y sin pantalla. El comando ejecuta el archivo del puente y luego cede el hilo principal al puente con serve_main_thread(); sin esa llamada, el comando termina y el puente termina con él.

blender --background --python boot.py

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

• El puerto empezó a escuchar 1,5 s después del inicio; get_state sobre hub enumeró blender como conectado, versión 4.3.2, versión del puente 1.
• Un script que construyó un cubo y lo renderizó a 128 por 128 píxeles devolvió status: ok con {"engine": "BLENDER_EEVEE_NEXT", "png": 10091}; el PNG era de 128 por 128 píxeles. El mismo script enviado una segunda vez tardó 0,12 s.
• El primer renderizado en un perfil nuevo tardó 30,5 s, y 31,2 s en la segunda ejecución, con el plazo del Hub elevado a 120 s. Con el plazo predeterminado de 30 s, cinco perfiles nuevos dieron cuatro ok entre 30,1 y 30,7 s y un timeout a los 30,0 s, tras el cual la llamada siguiente recibió busy hasta que terminó el renderizado. No se investigó por qué el primer renderizado es lento. Eleve default_timeout_s en la sección [hub] de config.toml, o renderice una vez a mano antes de que lo haga un modelo.
• get_state sobre blender devolvió la escena, sus objetos, el intervalo de fotogramas de 1 a 250, el motor de renderizado y los objetos seleccionados.

Una ejecución anterior, registrada en el diario (en inglés), encontró un bloqueo de bpy.ops.render.render llamado desde el propio hilo del puente en 1 de 23 intentos, y ninguno en 11 intentos con serve_main_thread(). Esa ejecución no se repitió aquí.

No se probó: iniciar el puente desde la consola del espacio de trabajo Scripting de un Blender abierto; una pantalla real; operadores de Blender distintos de añadir un cubo y renderizar; varias escenas. Una receta ejecutada con un modelo está en la página de Blender. Guía.

Inkscape

Inkscape 1.4, modo cli. No hay puente: el Hub inicia un proceso de Python por script, con /usr/bin/python3 y las extensiones de /usr/share/inkscape/extensions, y ejecuta inkscape una vez para exportar una captura. El único comando es la entrada de configuración:

[apps.inkscape]
enabled = true

• get_state sobre hub enumeró inkscape como conectado, versión 1.4, en el modo cli.
• Un script que añadió una capa Notes y un rectángulo devolvió {"layers": ["Layer 1", "Notes"]} en 0,16 s.
• get_state devolvió element_count 4, un ancho de 210mm, un alto de 297mm y las dos capas, y una captura PNG de 794 por 1123 píxeles con el modo 600.

No se probó: OMP_NUM_THREADS solo, sin OPENBLAS_NUM_THREADS (el módulo establece ambas); un documento más grande; una ventana de Inkscape abierta al mismo tiempo. Una receta ejecutada con un modelo está en la página de Inkscape. Guía.

LibreOffice

LibreOffice 25.2.3.2, modo uno. Un lanzador inicia LibreOffice con su ventana y luego el puente. La ejecución usó una pantalla X virtual y fijó el puerto UNO en 2102 y el puerto del puente en 9314 en config.toml.

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

• El lanzador volvió en 0,01 s, y 0,1 s después los tres destinos libreoffice-writer, libreoffice-calc y libreoffice-impress estaban conectados, con app_version en unknown. La guía lo explica: cuando el puente se inicia antes de que LibreOffice escuche, el Hub conserva unknown, la versión de su conexión actual, hasta que se conecta de nuevo. Siguió en unknown durante toda la ejecución. En la receta, el Hub se inició después de que LibreOffice escuchara, 1,3 s después del lanzador, y get_state dio 25.2.3.2. Una sonda UNO directa leyó 25.2.3.2.
• Sin ningún documento abierto, el script del ejemplo del README recibió doc = None, creó un documento de Calc y escribió A1 y B2. Devolvió {"a1": 42.0, "b2": "hello", "sheet": "Sheet1"} en 1,50 s; al repetirlo, 7 ms.
• get_state sobre libreoffice-calc devolvió la hoja y el documento Untitled 1 de la familia calc, y una captura PNG de 828 por 1170 píxeles con el modo 600.

En esta ejecución solo se manejó el destino Calc. Las dos pruebas del repositorio que manejan un LibreOffice real a través del puente, cargo test --locked --test libreoffice_real -- --ignored --nocapture, pasaron en 6,2 s. La versión 24.2.7.2, de los paquetes de Ubuntu 24.04, se probó antes, como registra el diario (en inglés); no se repitió aquí.

No se probó: una sesión de escritorio real; el PNG de un documento con varias hojas o páginas; qué documento es el actual cuando el foco está en otra ventana; un arranque en frío más lento que 5 s. Una receta ejecutada con un modelo está en la página de LibreOffice. Guía.

SiguienteVersiones →