Esta versión se puede considerar definitiva, así que a partir de ahora, en principio, y salvo que me envíen alguna idea loca y maravillosa que añadir, Autovala pasa a modo “mantenimiento”, subiendo sólo parches.

También actualicé mis extensiones de Gnome Shell para que funcionen con la versión 3.8, con lo que me considero libre para nuevos proyectos.

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.

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.

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.

Ahora sí puedo decir que tengo Gnome Shell como yo quiero.

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.

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.

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.

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.

Para ello, partí de los resultados publicados en La voz de Galicia del 2 de marzo de 2009 y de la lista de partidos que se presentaron en cada provincia, sacada de la Wikipedia. El proceso consistió en calcular el número de votantes que se abstuvieron a partir de los porcentajes de abstención de cada provincia, sumarle los votos en blanco y los de “Otros” partidos, dividir la cantidad entre los partidos que se presentaron en cada provincia, y aplicar D’Hondt para obtener el número de escaños en cada provincia mediante un programita en python.

Los resultados globales son éstos: a la izquierda están los resultados reales de 2009, a la derecha, los resultados en caso de que no hubiese habido abstención:

El resultado es, en mi opinión, muy interesante: el PP perdería la mayoría absoluta, y los partidos pequeños (que suelen ser mucho menos corruptos porque los que quieren chupar se van a los grandes, que es donde tienen posibilidad de pillar cacho) se vuelven decisivos.

A continuación, los resultados desglosados por provincias. En Lugo y Ourense sólo hay un gráfico porque los resultados son los mismos, pero en A Coruña y Pontevedra hay una diferencia abismal (pincha sobre cada imágen para ampliarlas):

Aquí está una tabla con los datos originales en los que me basé, obtenidos de La Voz:

Y los mismos datos, una vez repartidos los votos en blanco, abstención, y “otros”, y el correspondiente cálculo de escaños: