1. Introducción
Hace unos días leí vía OSNews un debate sobre si RISC OS debería ser OpenSource ("Should RISC OS be open sourced?"). RISC OS no es un sistema operativo que conozca de primera mano y la verdad es que no conocía cuál era su interfaz gráfica, si es que tenía alguna, pero entre los comentarios de OSNews encontré varias alabanzas a la GUI y un comentario que apuntaba que ROX ("RISC OS On X") clonaba la excelente interfaz original en Unix y además como software libre.
De ROX nunca había leído comentarios excesivamente positivos. No era más que otro programa del que había visto screenshots y que no me habían causado una impresión muy buena. En ellos ROX tiene una pinta un tanto retro y del montón sin nada digno de destacar salvo esos iconos azules enormes. Además lo tenía catalogado mentalmente como un simple "file manager" (nunca como un WM y mucho menos como un escritorio completo) y para colmo parecía un proyecto bastante marginal: de hecho en Fedora Core 4 ni siquiera se incluye (ni en core ni en extras, ni siquiera en los repositorios de RPMforge.net).
Pensando que algo tendrá el agua cuando la bendicen, me decidí a darle una oportunidad y... Me ha soprendido. Creo que ha llegado a mi disco duro para quedarse :-)
2. El escritorio
ROX es un entorno de escritorio que juega en la misma liga que Xfce. Se trata de un entorno de escritorio relativamente ligero para todos aquellos que no quieran o no puedan correr pesos pesados como Gnome o KDE. Digo "relativamente ligero" porque no hay que perder de vista que el toolkit gráfico que emplea es Gtk+2 y además varias de las aplicaciones que lo componen están escritas en Python. Probablemente no sea buena idea correrlo en nada inferior a un Pentium II con 64 megas de RAM y tarjeta gráfica acelerada en X (aunque hay
ROX para Zaurus). Una instalación típica no ocupa más de 8 megas en el disco duro.
El corazón del escritorio es el ROX-Filer que, además de ser gestor de archivos, puede manejar el "pinboard" (el fondo de nuestro escritorio), los paneles y la lista de aplicaciones minimizadas/abiertas sobre el mismo "pinboard".
Otros componentes destacados son ROX-Session o gestor de sesiones sobre DBus y OroboROX que es el WM. Junto a ellos hay varios applets y aplicaciones: AddApp, Archive, Clock, Edit, Fetch, Terminal...
El framework de desarrollo se compone de Gtk+2 y de la biblioteca ROX-Clib, de la que se incluyen además bindings para Python, Perl y Ruby.
Además de esto, trae su propia forma de paquetería para el manejo e instalación de aplicaciones. Esto, que a priori parece una mala idea ("¿para qué otro si ya tengo aptitude?" o "¿si actualizo con apt o con el suyo habrá interferencias?") no lo es tanto. Empezaré la descripción del entorno por este punto.
2.1 El sistema de paquetería: AppDir, los directorios ~/Apps ~/Libs y ~/Choices
A diferencia de Unix y de Windows y al igual que en Mac OS, las aplicaciones en ROX son autocontenidas. Para el usuario la aplicación aparece como un todo y no desperdigada por todo el sistema de archivos, como un icono que puede pinchar, configurar, mover donde quiera, instalar haciendo una copia y desinstalar simplemente borrando.
A este tipo de apliaciones se les llama AppDirs en la jerga ROX (presumiblemente jerga RISC OS) e internamente hablamos de un directorio que contiene el binario del programa, sus datos asociados, la ayuda, un icono (normalmente SVG), meta-información asociada en un archivo XML y un script AppRun que oculta los detalles y ofrece opciones normalizadas de arranque y configuración.
Para hacernos una idea más precisa haré una comparación con Klik. Klik es un proyecto reciente pero muy famoso que pretende hacer algo similar: distribuir aplicaciones autocontenidas con un mínimo de dependencias en un sólo archivo. En KDE-Hispano podéis leer una mini-introducción en castellano:
"Klik - copiar y borrar para instalar/desinstalar".
Ahora enumero los pros de una AppDir frente a un paquete Klik:
La AppDir no depende de Linux. Un paquete Klik (igual que los dmg de Mac) es un mini-sistema de archivos en un fichero, particularmente ramfs comprimido y montado vía loop. Un AppDir no es más que un directorio que contiene algunos archivos regulares y no necesita de ningún soporte especial en el kernel (cramfs y loop) para funcionar ni de ningún punto de montaje y/o modificación del fstab.
En la misma AppDir se puede distribuir varias versiones binarias de la misma aplicación, por ejemplo los ejecutables para PPC e IA32. En Klik es un paquete por arquitectura. De hecho el mecanismo de AppDir va un poco más allá y puede incluir también las fuentes del programa. Si el sistema no encuentra en el AppDir un binario apropiado para la arquitectura actual lanzará el proceso de compilación de manera transparente vía AppRun.
Dos críticas habituales que se le hacen a Klik son que malgasta el espacio al duplicar varias bibliotecas una y otra vez en cada paquete y que, en caso de que haya una bug en alguna de esas bibliotecas, hay que reemplazar todos los paquetes que la usen. El primer problema Klik lo palía con compresión pero para el segundo no propone nada.
Las AppDir no sufren esos problemas ya que las bibliotecas no se incluyen en cada aplicación sino que se distribuyen, a su vez, en formato AppDir. Para el usuario una biblioteca no es diferente de una aplicación: es un icono sobre el que puede pinchar (el sistema le dira que no es un programa, que es la biblioteca tal y es conveniente que la copie en el directorio ~/Lib), ver la documentación o recompilar de la forma habitual con AppRun.
Klik, por otra parte, tiene una ventaja importantísima y es que se pueden generar los paquetes automáticamente, directamente de los paquetes estándar de una distribución. A veces hay que pulir detalles a mano pero la mayoría de las aplicaciones pueden reempaquetarse en Klik sin tan isiquiera recompilar. Por contra, una aplicación contenida en un AppDir tiene que ser totalmente reubicable (la guerra que se libra en Autopackage), tiene que poder compilarse con el AppRun (esto es usando autoconf con un configure.in y unas macros propias) y hay que escribir a mano meta-información, interfaz de configuración y otros detalles. La parte buena de la historia es que existen wrappers
-ROX-Wrap- para muchas de las aplicaciones que podamos tener ya instaladas. Estos wrappers las hacen pasar por AppDirs aunque, evidentemente, si instalamos los rpm de Gimp éstos no se van a desinstalar simplemente porque borremos el wrapper ni se va a copiar la aplicación entera a otra máquina sólo copiando el wrapper. También hay una aplicación AppFactory que nos permite generar de forma sencilla nuestros propios wrappers.
Claro que para un usuario típico de Unix tanto AppDir como Klik pueden parecer una aberración y la verdad es que lo son pero... A veces AppDir puede resultar muy práctico: imaginemos un laboratorio con unas cuantas máquinas de arquitecturas diferentes (Alpha, Sparc32, Sparc64, PPC e IA32), todos corriendo Linux, ahora queremos compartir por NFS los homes y lo que se pueda para ahorrar espacio en los discos y simplificar la administración.
Los directorios con binarios y bibliotecas no son compartibles entre todos, hay que tener uno por arquitectura y en cada máquina montar el apropiado. También hay que tener una base de datos de los paquetes instalados por arquitectura (los paquetes deb que se instalaron, por ejemplo. Un /var propio por familia). Para instalar o desinstalar una aplicación hay que que hacerlo en las 5 arquitecturas correspondientes y a veces la configuración de un programa que funciona en una de ellas no funciona en la otra con lo que se hace difícil compartir las preferencias.
AppDir simplifica las cosas en este escenario: las aplicaciones se copian en cada home e incluyen, en el mismo AppDir, la versión para las 5 arquitecturas. Compartiendo /home, el usuario se puede sentar en cualquier máquina y siempre tendrá los mismos programas (con el plus de que puede instalarlos/borrarlos él mismo). La configuración de cada programa no está contenida en su AppDir sino en el directorio ~/Choices, siguiendo un estándar que similar al que se está escribiendo en
freedesktop.org (y que ROX adoptará cuando esté listo). Este estándar permite al usuario aplicar "perfiles de configuración" (para arquitecturas, en el ejemplo) de manera sencilla.
Dejando este ejemplo a un lado, quedan por abordar tres detalles de la paquetería en ROX: cómo se buscan los paquetes, cómo se maneja el tema de las actualizaciones automáticas y cómo se resuelve el tema del desperdicio de espacio: después de todo, si cada usuario instala sus propias AppDir en su $HOME podemos acabar con montones de copias de un mismo programa y/o de diferentes versiones de él, y lo mismo de sus bibliotecas. Para los tres la solución es la misma: 0install.
2.1.1 Zero Install o cómo correr el LGeneral desde la web
En primer lugar Zero Install o 0install no es propiamente una aplicación ROX, ni siquiera tiene porque ser una aplicación gráfica y con él puedes distribuir cualquier tipo de software pero, dado que todo ROX y la mayoría de las aplicaciones escritas para él usan este mecanismo o lo ofrecen junto con el típico tar.gz (con el AppDir dentro) y además está integrado en el escritorio mediante la aplicación AddApp, lo incluyo como una característica de la paquetería de ROX.
¿Qué es Zero Install?: una forma de distribuir software que permite correr aplicaciones sin tener que instalarlas. En cierto modo se podría decir que es la versión lenguaje-agnóstica y software libre de la tecnología Java Web Start de Sun. El usuario pincha en un enlace, o escribe "0launch url" y la aplicación se ejecuta sin más.
Está escrito en Python y la idea detrás es sencilla: Zero Install detecta a que elementos intenta acceder el programa, busca en la caché si están y los descarga en caso contrario.
Zero Install se integra en ROX y no sólo las aplicaciones, sino las bibliotecas (podemos compilar y enlazar contra bibliotecas obtenidas mediante 0install). La aplicación AddApp genera un wrapper AppDir automático. Así si tienes un AppDir "ROX-Filer" obtenido mediante 0install/AddApp puedes estar seguro al pinchar en ella de que siempre estarás corriendo la última versión, sin preocuparte de las actualizaciones ya que de eso se va a ocupar 0install: si ve que no la tienes se descargará los componentes que le hagan falta.
Zero Install puede funcionar de forma offline (siempre que no borremos la cache) u online (uso mínimo de la red o completo, con o sin caché), planificar actualizaciones globales, manejar dependencias, firmas digitales y soporta ramas (estable, inestable, etc.). Además la caché puede ser compartida entre todos los usuarios, de manera que las aplicaciones que corre uno no las tiene qué volver a descargar 0install para otro.
2.1.2 No es oro todo lo que reluce
¿Ya estás convencido de que AppDir es panace? bueno pues si es así permiteme desconvencerte :-). Hay un fallo muy gordo en todo esto y que no tiene solución. Ni con el sistema de AppDir's por si sólo ni añadiendo 0install podemos manejar dependencias.
Quiero decir que 0install o una AppDir puede saber de qué depende tal o cual software adicional pero no puede saber qué tenemos instalado ya en nuestro sistema (vía apt, por ejemplo) así que el sistema está cojo: 0install podría descargarse aplicaciones que no funcionan porque no tenemos instaladas las bibliotecas "de sistema" necesarias (las que él no conoce y que da por supuesto que están). Los scripts de Python en ROX normalmente muestran mensajes adecuados si no encuentran tal o cual módulo en el $PYTHONPATH pero en aplicaciones en C muchas veces no veremos nada, son fallos silenciosos. Ni siquiera un script de Python mostrará algo si no tenemos instalado el intérprete de Python: ese tipo de cosas son las que no chequea 0install.
En realidad tampoco Klik lo hace aunque su aproximación de incluir un montón de bibliotecas en los paquetes lo hace un poco más robusto ante este problema. Con todo, sin kdelibs no podemos esperar que funcione el paquete Klik kmines.cmg.
Salvando ese pequeño problema (lógico teniendo en cuenta que estamos haciendo coexistir dos sistemas de paquetes incompatibles) el tema funciona razonablemente bien.
2.2 ROX-Filer
El ROX-Filer es, como ya he dicho antes, el verdadero corazón del escritorio. Se puede comportar como un vulgar gestor de archivos pero también puede ofrecer paneles para anclar aplicaciones y applets, y un "pinboard" donde añadir atajos a aplicaciones, directorios, puntos de montaje, etc.
ROX-Filer permite guardar varias configuraciones del "panel" y del "pinboard", asociando a cada una un nombre, de manera que podemos arrancar con paneles con iconos diferentes (una configuración para trabajar y otra para ocio, por ejemplo) pero por lo demás esos dos son bastante convencionales. Voy a centrarme en lo que es el gestor de archivos en si.
El aspecto visual por defecto es un poco desangelado pero no es tan malo como parece: está escrito en Gtk+2 y todo lo que ves es themeable así que es cuestión de cambiar los iconos y el tema de Gtk+2 al gusto. Una vez superado la repulsa inicial nos encontramos con que llamar austera a la interfaz es quedarse corto, muy corto: una barra de tareas con 8 botones (sin texto), una etiqueta indicando el número de elementos en el directorio que estamos navegando y ya está: ni menús, ni barra de estado ni nada parecido. No hay opción para trabajar con dos paneles ni parece haber opción para seleccionar archivos (aparte de un botón de Seleccionar todo/Invertir Selección) ni para visitar un directorio sin pasar por todo el árbol antes a base de clicks (botón derecho modo navegación, botón central modo espacial). Todo está oculto mediante atajos de teclado y menús emergentes.
Una característica muy potente de ROX-Filer es su línea de órdenes o mini-cli: si pulsamos "/" se nos permite escribir la ruta directamente en un cuadro de texto en la parte inferior de la ventana y aquí un inciso sobre la filosofía del entorno: los únicos diálogos son muy poco frecuentes y nunca modales. Es habitual que las aplicaciones saquen sus "diálogos" (como este mini-cli) en la parte de abajo de la misma ventana. Otros ejemplos son las barras de progreso o el diálogo de buscar palabras que no muestra un diálogo emergente sino que usa el mismo sistema que Firefox: diálogo integrado y abajo. Otra curiosidad es que no existen las barras de menús: el menú de todas las aplicaciones siempre es emergente, con botón derecho del ratón.
Volviendo al mini-cli del Filer, hay auto-completado pulsando el tabulador y con la tecla de retroceso subimos un nivel en el árbol de directorios ("retrocedemos un tramo" en el path). Mientras escribimos los directorios el contenido de la ventana va actualizándose en consecuencia, en segundo plano y muy rápidamente (incluso con thumbnails ROX-Filer saca chispas en mi máquina comparado con Nautilus y Konqueror).
El autocompletado también funciona como filtro: si por ejemplo tenemos un directorio con tres archivos "ejemplo1.txt", "ejemplo2.txt" y "ejemplo3.txt", junto con unas cuantas decenas más, al completar "ejemplo" en la mini-cli restringimos el desplazamiento del cursor de selección de los archivos (el que se puede mover con las flechas de dirección) a esos tres nada más. Para seleccionar archivos por patrones se pulsa "." y aparece otra mini-cli en la que podemos escribir expresiones regulares completas más potentes que el glob de la shell.
Copiar, mover, enlazar, etc. A todo se accede con alguna combinación de botones de ratón (usa 3) y teclas. Con todo esto cuesta hacerse con el control pero después es de lo más eficiente. Usar el mini-cli es como tener una consola de texto pero con iconos y realimentación visual.
Copiar, mover, enlazar y demás se apoya en el Drag&Drop. No parece una práctica extraña (casi todos los gestores de archivos lo hacen, ¿no?) pero ROX-Filer lo lleva al extremo. Por ejemplo, para asociar una acción a un tipo MIME o a un archivo concreto hay que arrastrar una aplicación sobre el area de acción. Todo se hace arrastrando y soltando: cambiar iconos, modificar menús como el de "Enviar a...", añadir applets a un panel, instalar aplicaciones, descargar archivos, descomprimir...
Pinchando sobre un AppDir, éste arrancará por defecto. La meta-información contenida en el AppDir sirve para modificar los menús contextuales del Filer, de manera que si sobre lo que pinchamos con botón derecho es una aplicación nos dará la opción de navegar por dentro o de configurarla o de verificar las versiones (si es un 0install). Los puntos de montaje de los dispositivos también los trata de manera especial: mostrando si están montados o desmontados, con opciones de desmontar, expulsar CD...
Un buen detalle es que a cualquier elemento (directorio, punto de montaje, programa) le podemos asignar un atajo de teclado global.
2.3 Otras aplicaciones
Con ROX vienen o se pueden instalar muchas pequeñas aplicaciones: applets como SysTray, Pager, Volume, TaskList o el XDG-Menu, que permite tener un botón con los menúes según estándar XDG de freedesktop.org (el que sigue las últimas versiones de Gnome, en las que hay que editar los menúes con Smeg), un editor "Edit" basado en GtkSourceView, con realzado de sintaxis y demás, Album que permite hacer AppDir con colecciones de MP3/OGG Vorbis y que se reproduzcan con un click o un grabador de CD's a golpe de Drag&Drop.
Hay una lista más o menos exhaustiva en la web de ROX:
Software Index y Desktop Utilities.
Un programa que merece un poco más de atención es OroboROX, el gestor de ventanas. OroboROX es un gestor muy sencillo, integrado y con un buen soporte de temas. Consume poca memoria pero por contra no tiene muchas opciones. Por ejemplo el interfaz para configurar el comportamiento de las ventanas según su WM_CLASS es casi inexistente (habrá que tirar de Devil's Pie) pero no es eso lo que me interesa.
Como ya dije, en ROX-Filer (y en ROX, por extensión) todo se hace con Drag&Drop. Por desgracia esto no funciona muy bien con el sistema de foco típico de Windows (y que han adoptado por defecto la mayoría de WM, incluidos los de KDE y Gnome). Para ilustrar el problema pongo un ejemplo:
Imaginemos que estoy visitando la página de LGames y quiero echar una partida al LGeneral. Entonces tengo que arrastrar el enlace 0install de Firefox hasta la ventana en la que tengo AddApp pero... Firefox lo tengo maximizado y, en el momento que pincho en el enlace para arrastrarlo, la ventana de Firefox pasa a primer plano y tapa la ventana donde está AddApp. Para poder llevar el enlace hasta el instaldor primero he de cambiar el tamaño de la ventana de Firefox, con la correspondiente molestia.
Por eso el manejo del foco por defecto en OroboROX es diferente al habitual: si pinchas en el contenido de la ventana ésta obtiene el foco pero no pasa al primer plano. Es decir, que al pinchar en el enlace en Firefox para arrastrarlo, Firefox no pasa al primer plano tapando la ventana de AddApp, sino que esta sigue estando ahí (el efecto es como si la configurásemos para estar siempre encima). Al arrastar el enlace dentro de AddApp, su ventana gana el foco y todo funciona correctamente. Para conseguir que una ventana pase a primer plano hay que pinchar en el marco de la ventana (la barra de título o los laterales) o bien hacerse una combinación de teclas.
No es obligatorio usarlo así pero después de un rato con él se llega a la conclusión de que es la forma más efectiva de entre las propuestas (la típica de Windows/Mac, la típica de Unix y esa) para poder explotar el Drag&Drop.
2.4 ROX-CLib
La interfaz de programación usual de ROX está compuesta de Gtk+2, una biblioteca C propia y el correspondiente binding Python (ROX-Lib2) más libxml2. La biblioteca ROX-CLib no es demasiado extensa y ofrece las siguientes funcionalidades:
Sobre Gtk+2 sólo aporta un widget nuevo pero merece la pena explicarlo. Se trata de GtkSaveBox y con él descubrimos una de las características más curiosas de ROX: no hay diálogo de selección ni de guardado de archivos. ¿Cómo funciona entonces? pues para abrir es sencillo de adivinar: usaremos Drag&Drop de los documentos sobre sus aplicaciones. ¿Y para salvar?... También Drag&Drop. ROX usa el protocolo XDS (otro estándar de freedesktop.org y van...) para salvar los archivos. Desde el punto de vista del usuario funciona así:
Supongamos que acabas de escribir algo con Edit y pulsas el icono de Guardar. Aparece una ventana no modal (el GtkSaveBox) con un cuadro de texto con el nombre y un icono que representa el archivo. Sólo tienes que darle un nombre, y arrastrarlo donde quieras guardar. En el Artículo de ROX de la Wikipedia hay un screenshot que ilustra perfectamente esta característica.
Hace algún tiempo comenté en Libertonia algo parecido, al hilo de una
Comparación entre el diálogo selector de archivos de Gnome y el de KDE
Quizás la solución ideal [para Gnome] sería una ventana de Nautilus, que al pinchar en "Abrir" te aparezca una ventanita del Nautilus del último directorio en el que guardaste y ahí puedas pinchar lo que quieras o arrastrarlo directamente en la aplicación. Un comportamiento bastante consistente, creo yo: para tener un mal diálogo mejor no tener ninguno.
Perdón por lo egocéntrico de citarme a mi mismo pero me ha sorprendido: por aquel entonces no conocía ROX pero implementa prácticamente lo mismo en lo que estaba pensando, tanto para abrir como para salvar.
Otra funcionalidad que nos aporta el API es el soporte para SOAP, tanto para clientes como para servidores. Aún no lo había mencionado pero las aplicaciones ROX pueden comunicarse entre ellas por medio de peticiones SOAP y nosotros también podemos invocar funciones de manera programática desde C, un script Python o incluso desde la shell en el caso del Filer, de manera bastante similar a como lo haríamos con DCOP en KDE.
La interfaz SOAP de ROX-Filer está descrita en el manual pero, para hacernos una idea, abrir un directorio tiene esta pinta:
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body xmlns="http://rox.sourceforge.net/SOAP/ROX-Filer">
<OpenDir>
<Filename>/tmp</Filename>
</OpenDir>
</env:Body>
</env:Envelope>
Y esto se podría mandar directamente con el API de SOAP en ROX, aunque para el caso particular de ROX-Filer se nos ofrece también una interfaz simplificada. Hay varios añadidos construidos sobre esto: por ejemplo el soporte para dispositivos extraibles vía HAL. Un script se encarga de añadir/quitar del panel los iconos de los dispositivos cuando estos se conectan, comandando los paneles mediante SOAP.
Por completar, ROX-CLib también incluye funciones para soportar el Drag&Drop (XDND, XDS, decodificación de URI's, etc.) que trabajan con widgets Gtk+ y las API's más o menos previsibles: manejo de la configuración (las Choices) e interfaz de opciones "a lo ROX", diálogos de información y error, lectura de meta-datos (AppInfo.xml), MIME y programación de applets. La filosofía general es la de registrar retrollamadas (punteros a función)
3. Despedida y cierre
Esto es todo lo que tenía que he investigado sobre ROX los tres días que llevo jugando con él.
En definitiva, pienso que es un gran programa y no me explico por qué es menos popular que, digamos, Xfce cuando EMHO es bastante superior tanto desde el punto de vista de productividad como en el tecnológico. No es lo mismo de siempre (leasé lo mismo que Mac o Windows) y exige un pequeño periodo de aprendizaje pero es eficiente, práctico e incluso bonito con un tema adecuado. Es tan práctico que este friki que para hacer casi cualquier cosa con los archivos tira de consola ha descubierto que se puede vivir sin abrirla más que para cosas puntuales :-). Por cierto, ROX no incluye su propio emulador de terminal, la aplicación Terminal delega en xterm, rxvt, aterm o lo que tengamos instalado. A mí personalmente me gusta Terminal (nombre original donde los haya): es un emulador completo, con pestañas y helpers para manejar urls, y con pocas dependencias.
¿Hay otros programas que penséis que están infravalorados?, aplicaciones cuyo nivel de popularidad es bajo pero para vosotros son de las mejores de su clase.