Hito en Autovala

Acabo de subir al repositorio la versión 0.10.0 de Autovala  y creo que supone un hito importante, porque con ella he cubierto todas las ideas iniciales que tenía. La principal, y más difícil, es la de incluir en un mismo proyecto un ejecutable y una biblioteca, y que ese ejecutable se enlace con dicha biblioteca, todo de manera automática y sencilla.

Ahora me queda descubrir como trabaja intltool-extract e intltool-merge con las entradas .desktop, para permitir la traducción sencilla en estos casos, y ver como mezclar ficheros .c con .vala. También la idea de integrarlo en Gedit, pero eso con mucha más calma.

Simplificando Vala y CMake

He estado tres semanas currando sin parar en mi trabajo-que-paga-las-facturas, y aunque no pude disfrutar ni findes ni vacaciones (¡Gracias, gracias, ministros que pusieron la fecha de entrega de los innterconecta para justo después de semana santa! ¡Así os salga un cardo en el sobaco!), sí pude aprovechar algunos ratos muertos en casita para hacer un proyectillo personal: Autovala.

La idea detrás de Autovala surgió de casualidad de una lista de correo: un usuario se quejaba de que trabajar con CMake era muy pesado, y que obligar a usarlo para los proyectos de la lista sólo conseguía reducir la cantidad de desarrolladores que estarían dispuestos a colaborar. Y la verdad es que tiene algo de razón: empezar un proyecto nuevo con CMake es una tarea realmente aburrida, por la sencilla razón de que es muy repetitiva.

Pero cuando una tarea es repetitiva… es ideal para que la haga una máquina. Así que mi idea fue: ¿por qué no dejar que sea el propio ordenador quien genere de manera automática los ficheros CMake?

Y esa es, precisamente, la idea detrás de Autovala: generar de manera automática todos los ficheros para CMake, en base a una serie de heurísticos. Así, por defecto, todos los ficheros .vala que haya en el directorio src (o subdirectorios dentro de él) se compilarán juntos para hacer un único binario. Además, añadirá automáticamente los paquetes necesarios para cada fichero, para lo que echa un vistazo a las directivas using del propio código. Lo mismo para otros elementos: por ejemplo, para los iconos comprobará qué tamaño tienen y, en base a ello, decidirá automáticamente en qué carpeta deben ir. Y más, mucho más.

Por supuesto, es posible añadir excepciones a mano para ajustar aquellas cosas en las que las reglas no funcionen bien; por ejemplo, si lo que queremos es generar una biblioteca, o si nuestro proyecto está compuesto de varios ejecutables. La ventaja en estos casos es que sólo hay que hacer eso: indicarle que queremos que sean dos, tres, o los que sean, ejecutables y donde buscar las fuentes; autovala seguirá haciendo el resto automáticamente (buscar paquetes necesarios, etc). Además, los cambios que haga el usuario se recuerdan, por lo que si se añaden o eliminan ficheros, basta con recrear el fichero de proyecto, y se tendrán en cuenta todas las excepciones hechas antes.

Obviamente Autovala no sirve para todos los proyectos, pero sí para la gran mayoría, que es lo interesante.

Clonando Elementary OS en Gnome Shell

Pues eso es lo que he estado haciendo fundamentalmente este mes, porque poquito a poquito, slingshot_app_launcher para Gnome Shell ya funciona exactamente igual que la versión original de Elementary OS: no sólo permite escoger entre mostrar por categorías o todo junto, sino también buscar aplicaciones tecleando su nombre. Además, he corregido algunos bugs en el tamaño de la ventana (también funciona en monitores pequeños), y lo he hecho mucho más compatible con los CSS de Gnome Shell, de manera que si cambias el estilo (o tema), el menú se ajustará a éste.

Por otro lado, aproveché también para subir la última versión de Transmission para WebTV, donde únicamente actualicé la versión de transmission a la última, la 2.77.

Cronopete, WebTV y Gnome Shell

Desde mi última entrada hasta hoy he hecho unas cuantas cositas, pero no las comenté por aquí por falta de tiempo. Y dado que al final no se ha acabado el mundo, vamos a retomar las buenas costumbres.

En primer lugar, lancé una nueva versión de Cronopete, la 3.6.0, que justo hoy actualicé a la 3.8.1. El principal cambio ha sido un lifting de la interfaz de restauración de ficheros, además de incluir paquetes .deb con las versiones GTK2 y GTK3.

Por otro lado, lancé una nueva versión de Transmission para WebTV, la 5.0. En ella, además de incluir la última versión de Transmission, he recompilado todas las bibliotecas desde cero para tener las más recientes y he sustituido el viejo periscope por mi versión modificada de submarine. Ahora, por fin, vuelven a funcionar los subtítulos. Por desgracia, el autor aún no ha mezclado mis cambios con su rama, así que le he escrito y estoy esperando su respuesta.

Por último, he vuelto a Gnome Shell desde Elementary. El motivo es que necesito tener iconos en el escritorio, y de la forma que trabaja Gala (el gestor de ventanas de Elementary) no es nada cómodo hacerlo: cada vez que un escritorio virtual se queda sin ventanas abiertas, se mueve al anterior automáticamente. Aunque en Gnome Shell ocurre algo parecido (cambia a modo Actividades u Overview) tiene la ventaja de que se pueden añadir extensiones de manera relativamente sencilla. Pero a la vez echaba de menos algunas características de Elementary, así que me lié la manta a la cabeza y escribí dos:

  • Slingshot: se trata de un clon para Gnome Shell del menú lanzador de aplicaciones de Elementary.
  • AvoidOverview: elimina, precisamente, el molesto cambio de modo cuando se cierran todas las ventanas de un escritorio, pero permitiendo que se siga accediendo mediante los hotspots, el botón de Actividades, o la tecla windows.

Reconozco que la elección de JavaScript para crear Gnome Shell me resultaba curiosa al principio, pero ahora que he escrito estas dos extensiones puedo entender los motivos: gracias a la técnica de Monkey Patch, es posible cambiar el funcionamiento de cualquier parte del escritorio sin necesidad de modificar los fuentes originales, porque JavaScript permite modificar en caliente los métodos de un objeto. Esto no es necesario cuando simplemente se quiere hacer un módulo sencillo que incluya un menú, un icono, un botón, etc. pues para ello existe una API muy bien definida. Este es el caso de Slingshot, que no necesita ninguna de estas técnicas.

Sin embargo, para cambiar la forma en que responde el escritorio en funciones muy internas, como hace AvoidOverview, no queda más remedio que usarlas. Y aunque reconozco la potencia y versatilidad que ofrecen, tengo que decir que no me gustan demasiado, porque no puedo evitar ver el resultado como sucio. La apariencia no es la de un módulo que se enchufa en un punto específico mediante una interfaz bien definida, sino la de un parche aplicado con cinta aislante, cortando pistas del circuito impreso, y sujetando todo con una brida.

Pese a todo, en conjunto creo que el resultado ha sido acertado, porque de limitarnos exclusivamente a una API para módulos, probablemente no se podría jamás incorporar un cambio en algo tan profundo como esto. No olvidemos la postura de Gnome de reducir al mínimo las opciones de configuración del escritorio: no creo que aceptasen ni cambiar en la rama oficial el funcionamiento del modo Overview, ni incluir la opción de configurarlo.

Esto le da un nuevo sentido a un comentario que leí sobre Gala, el gestor de ventanas de Elementary OS, que también está basado en la tecnología de Gnome 3 (y que, por desgracia, no recuerdo donde la leí). Venía a decir que lo importante no es tanto el escritorio en sí, sino la tecnología que hay debajo, con mutter y demás, porque con ella se pueden hacer nuevos escritorios con facilidad, como es el caso de Gala o Cinnamon. Y así es: no hace falta que en la rama principal se añadan todas las opciones imaginables, porque es perfectamente posible modificar el funcionamiento interno con bastante facilidad, y simplemente añadiendo unas cuantas extensiones se puede cambiar de arriba a abajo la forma de trabajar del sistema.

Para aquellos que quieran saber cual ha sido mi elección, comentar que, además de AvoidOverview y Slingshot, tengo las siguientes extensiones:

  • Coverflow Alt-tab: cambia el funcionamiento de las teclas Alt+Tab por un cambiador al estilo cover-flow, además de mostrar sólo las ventanas del escritorio actual.
  • Hide Dash: elimina el dash (barra de aplicaciones situada a la izquierda). Lo tengo porque prefiero tener plank en la parte baja de la pantalla.
  • No top-left hot corner: desactiva el hotspot de arriba a la izquierda, que permite entrar en el modo Overview. Necesario porque, si no, es muy fácil que se active cuando se intenta lanzar una aplicación desde Slingshot.
  • Remove Accesibility: elimina el icono de configuración de la accesibilidad. Cabe señalar que es la extensión más descargada para Gnome Shell… por algo será 😉

A mayores también tengo System-Monitor y Workspace navigator, pero esas ya son por gusto propio. Con estas extensiones, y activando Nautilus para que gestione los iconos del escritorio, he podido darle la vuelta por completo a la forma de trabajar de Gnome Shell, ajustándolo exactamente a como yo lo quiero.

Subtitulando

Estos días estoy liado buscando alternativas a periscope para bajar subtítulos de manera automática. El motivo es que no es un proyecto que esté siendo mantenido de manera razonable.

De casualidad encontré subliminal, un programa similar pero con más fuentes de subtítulos, y decidí echarle un ojo. La verdad es que funciona muy bien, pero tiene el inconveniente de que, al igual que periscope, está escrito en python, lo que significa que hay que meter una máquina virtual completa en mi WebTV.

Pero de casualidad encontré submarine, otro programa similar pero escrito en Vala, lo que significa que puedo compilarlo en un ejecutable y ahorrarme todo el interprete de python. Por desgracia, este sólo soporta búsquedas en OpenSubtitles.org y en Podnapisi.net. Sin embargo, su modelo interno es tan sumamente sencillo que he conseguido añadir soporte para SubDB (el cual ya está subido a mi repositorio GIT personal y solicitado un commit al oficial).

Extraoficialmente también he conseguido implementar soporte para BierDopje, pero ese código todavía no lo puedo subir porque sigo a la espera de que me concedan una clave específica para la API (en estos momentos estoy usando prestada la de subliminal, pero cada aplicación tiene que usar la suya propia).

El uso de este portal tiene su complicación, en buena medida porque mientras que SubDB utiliza un hash del archivo para buscar subtítulos, BierDopje pide el nombre de la serie, la temporada y el capítulo. En subliminal se utiliza la impresionante biblioteca guessit, que, a partir del nombre del fichero, y mediante una serie de heurísticos, extrae toda la información posible sobre un fichero. Obviamente dicha biblioteca está escrita en python, así que tuve que hacer una versión de andar por casa en Vala. El concepto básico es el mismo (de hecho, fusilé todo lo que pude), pero, al estar hecha en una noche, no es tan precisa. Obviamente acepto parches para mejorarla.

Para jugar bien

En la entrada anterior explicaba el problema que supone jugar cuando se utiliza un gestor de ventanas por composición. Este problema se describe con más detalle en los artículos The Cost Of Running CompizMutter Can Cause A Gaming/OpenGL Performance Hit Too. El principal motivo es que los programas no pintan directamente sobre la pantalla, sino sobre un buffer oculto, y es el gestor de ventanas el que, de manera periódica, copia dicho buffer a la zona visible.

La solución que proponía era aumentar la prioridad del gestor de ventanas y del servidor X, pero dado que es una operación algo liosa para alguien que no tenga unos mínimos conocimientos, decidí hacer un pequeño programa que lo automatizase. Ese programa se llama GAMEd. La esencia es muy sencilla: tenemos una lista de ejecutables almacenada en /etc/gamed.conf. Cada vez que se lanza el gestor de ventanas y el entorno de escritorio, se llama mediante DBus al demonio GAMEd (y si no estaba lanzado, el propio DBus lo lanza como root). Este demonio recorre la lista de procesos actuales, y cambia su prioridad a cada uno que coincida con alguno de la lista. De esta manera es posible asignar prioridades altas desde el espacio de usuario sin abrir un agujero de seguridad, porque sólo se cambiarán aquellos programas autorizados.

El sistema está diseñado para ser completamente transparente: por defecto asigna prioridad -15, pero se puede utilizar el comando renice_gamed para escoger cualquier otra (podría llegarse hasta -20, pero en el código de un programa similar, AutoNICEd, recomienda no hacerlo, así que GAMEd simplemente redondea a -15 si se pone una prioridad mayor). Dicha prioridad se almacena y se utiliza todas las veces que se llame al demonio, hasta que el usuario la vuelva a cambiar si quiere.

Por otro lado se añade un pequeño script en el arranque del escritorio, que llama al demonio. Esto hace que cada vez que se arranque el ordenador y se entre en la sesión, se ajustará de nuevo automáticamente la prioridad de las X y del gestor de ventanas.

Yo lo he probado en Gala y en Compiz y se nota la diferencia, pero no he podido probarlo en Gnome-Shell por ciertos problemas de compatibilidad de paquetes entre éste y Elementary OS.

Así pues, si jugáis regularmente en vuestro equipo Linux y notáis pérdida de rendimiento y de FPS en vuestros juegos, probad a instalar GAMEd y contadme qué tal os ha ido.

Juego elemental

Llevo una temporadita probando Elementary OS, y tengo que decir que me encanta. Es un concepto de escritorio y sistema operativo que, salvo un par de detalles, encaja como un guante en lo que busco. Tanto es así que estoy asegurándome de que Cronopete esté perfectamente integrado en él.

Por otro lado, hace poco descubrí Limbo, un juego con una ambientación sencillamente impresionante.

Sin embargo, me encontré con que la mezcla de ambos no funcionaba muy bien: había «saltos» entre fotogramas, se conseguían muy pocos FPS y había un retardo brutal (casi un segundo) entre la pulsación de una tecla y que el personaje ejecutase la acción correspondiente. Al principio lo achaqué a Wine (es un juego para windows), pero buscando información encontré que al resto de gente le funcionaba perfectamente.

Lo primero que hice fue cambiar del driver privativo de AMD/ATI (FGLRX) al libre (Radeon), y los saltos desaparecieron, pero los bajos FPS y el retardo seguían allí.

Recordé que había una crítica general contra los gestores de ventanas por composición como Compiz, Mutter y KWin, porque tienen que renderizar el contenido de cada ventana cada vez que la aplicación lo cambia. Ante esto, probé a arrancar una sesión de gnome-fallback-session, y allí funcionaba perfectamente, lo que confirmó que el problema estaba en Gala (el gestor de ventanas de Elementary).

Sin embargo, pensando, llegué a la conclusión de que perfectamente podía deberse al retardo en la conmutación entre tareas, así que decidí probar a asignarle máxima prioridad (-19) tanto al servidor X como a Gala. Para ello usé el comando renice (como root, porque si no, no permite asignar valores negativos, correspondientes a la máxima prioridad). Con eso el problema se resolvió, y el juego funcionó con una suavidad total, igual que si no estuviese utilizando un gestor de ventanas por composición.

PPAs

Tras arduos intentos, por fin he conseguido crear un repositorio PPA para Cronopete. Gracias a él, los usuarios de Debian, Ubuntu y Elementary OS tendrán mucho más fácil instalarlo. También gracias a esto he conseguido pulir algunos problemillas en los scripts de CMake, para que funcione al 100% la instalación en directorios no estándar.

En cronopete en sí casi no hay cambios, salvo haber añadido soporte de D-Bus activation, para que si no está lanzado, y el usuario hace click en el icono de configuración o de restauración de archivos, se lance automáticamente.

Lo que no he conseguido aún es que, tras instalar el paquete, el sistema pida al usuario reiniciar (y que así se lance Cronopete en el siguiente arranque).

¡A disfrutarla!

Lavado de cara

Después de unos cuantos años con la misma apariencia, y varios comentarios de otra gente, me decidí a cambiar un poco el diseño de mi web. No es que sea un cambio radical, pero al menos está más limpio.

Por otro lado acabo de lanzar la versión 3.4.0 de Cronopete (sí, he decidido usar números de sub-versión impares para las versiones de desarrollo), con varias novedades internas. La principal es que ahora utilizo CMake para compilarlo, por lo que será más fácil que terceros hagan paquetes DEB o RPM. Por otro lado, he simplificado los mensajes y retocado los gráficos, además de portarlo a appindicator. Todo esto con el objetivo de que sea incorporado a Elementary OS en un futuro cercano (o lo que es lo mismo: en la versión siguiente a Luna).

Que la disfrutéis con salud.