GTK+ 3.0

De Gnome 3 y su nuevo Gnome Shell no hay mucho más que decir, ya está todo el pescado vendido. ¿Y que hay de GTK+? En realidad, lo más interesante son siempre los cambios en la maquinaria, los que no se ven, ya que son los pilares que hacen que una casa se sostenga o no.

GDK: En primer lugar, han rediseñado GDK -la parte de GTK+ que se encarga de interactuar con el sistema gráfico- por completo. GDK estaba modelado, por razones históricas, para encajar con el diseño de las APIs de X.org; lo cual, además de dificultar la portabilidad, era un poquito vetusto. Ahora está diseñado para encajar con el diseño de la librería gráfica Cairo (antes ya usaban Cairo en muchas partes, ahora la usan para todo), cediéndola ya de paso gran parte del tedio de la portabilidad. Siendo realistas, más que una gran mejora, esto es un adecentamiento para ponerse al nivel de otros toolkits bien diseñados (como QT). Pero no deja de ser interesante.

'Backends': Otra novedad en el campo de GDK es que se pueden compilar varios "backends" gráficos en el mismo binario y decidir cuál utilizar en tiempo de ejecución. Por ejemplo, se puede compilar GTK+ con soporte de Wayland y de X.org simultáneamente, y optar por uno u otro dependiendo del contenido de la variable GDK_BACKEND (o autodetectarlo), lo que permitirá que las distribuciones incluyan Wayland y X.org sin tener que preocuparse de que las aplicaciones funcionen o no. Esto es muy bonito, aunque QT lleva pudiendo hacer lo mismo (por ejemplo, "kword --graphicssystem opengl" abre un kword acelerado con OpenGL - desgraciadamente, el mal estado de las implementaciones OpenGL en Linux impide utilizarlo por defecto) desde 2008.

CSS: La siguiente novedad es la capacidad de diseñar themes con sintaxis CSS. Algo que, seguro que se sorprenden, QT ya tenía desde 2006.

Dconf: Han decidido reemplazar Gconf, ese sistema que se encarga de gestionar las configuraciones de ~/.gconf, con un nuevo invento: Dconf + Gsettings. Dconf sería el "backend" de almacenamiento en el disco de las configuraciones, y Gsettings la interfaz que utilizan las aplicaciones para acceder a él. Gsettings puede utilizar varios backends, pero es obvio que está optimizado para utilizar Dconf en Linux. La novedad principal de Dconf es que todas las configuraciones se guardan en un solo archivo binario (seguro que dará mucho que hablar cuando la gente se entere), y la ventaja es que el rendimiento es mucho mejor.

XInput2: Soporte para la extensión de X.org XInput2. XInput2 es una API alternativa que reemplaza el actual infierno de gestión de dispositivos de entrada de X.org por algo decente. En XInput 2.1 -que, desgraciadamente, no entró en la última versión de xorg-server, y tendrá que esperar a la de mediados de este año- se añade buen soporte para multitouch, y los toolkits (también QT) lo soportarán por defecto.

Height-for-width: Esta es una característica muy vaga de una parte de GTK+ llamada "gestión de geometría", y que en la práctica consiste en decidir dónde se colocan las cosas y qué ocurre al redimensionar la ventana. Este nombre tan rimbombante de "height-for-width" quiere decir que a partir de ahora cada widget informará al gestor de geometría de hasta qué punto es apropiado redimensionarle o no, para que pueda redimensionar las cosas como debe ser y no haga cosas como, por ejemplo, lo que ocurre en el caso 3 de esta imagen (algo que puede evitarse con hacks, pero que se soporta correctamente con esta nueva característica). QT lo soporta desde hace tiempo (mínimo 2001).

Gobject introspection: Se ha añadido soporte para introspección en Gobject, lo cual es útil principalmente para automatizar la creación de bindings de otros lenguajes. Una vez que un determinado binding de un lenguaje utilice esta introspección, no necesitará ser "actualizado" cada vez que una nueva versión de GTK+ añada nuevas APIs, como ocurre hoy, y permitirá mayor colaboración entre programas escritos en varios lenguajes. Una vez más, KDE...

Renderizado "offscreen": Esto es algo que se podría simplificar como "capacidad de dibujar en un buffer de memoria". Para entenderlo, hay que resumir en breve la evolución del renderizado de GUIs en Linux. En un principio teníamos las APIs de X.org, que eran del tipo "dibuja un círculo", "dibuja la letra a": el servidor gráfico se ocupaba de renderizar él mismo esas cosas tal y como se le pedía. Entonces vino Keith Packard del cielo y trajo consigo la extensión XRender, que implementa un modelo de composición de imágenes para permitir que las aplicaciones, y no el servidor, tomaran parte en el renderizado. Eso hizo que pasaramos a tener librerías como freetype, que renderizan, a peticion de las aplicaciones, las fuentes con antialiasing y lo que haga falta, y el toolkit va pidiendo al servidor, vía XRender, que dibuje las cosas aquí o allá. De ese modelo, que es el actual, pasamos al del futuro: Las aplicaciones pasan completamente de APIs como XRender, renderizan absolutamente todo por si mismas. Es el modelo de Wayland, la aplicación dibuja lo que quiera en un buffer de memoria que representa a la ventana de la aplicación -ubicado en la memoria de la GPU y generado mediante OpenGL, si quiere-, y cuando se termina de dibujar se notifica al servidor gráfico, que se limita a juntar las imágenes de todas las ventanas, dibujar la imagen final, y enviar el buffer a la salida de vídeo. GTK+ 3 soporta este modelo, y gracias a ello puede incorporar soporte de Wayland con mucha facilidad.

No hay mucho más que contar de las cosas nuevas que incluye GTK+ 3.0. Si que habría que comentar algo de las que no incluyen: animaciones complejas, del estilo de Core Animation o QT QML. ¿Por qué? Porque GTK+ se ha dado completamente por vencida en este aspecto, y lo deja todo en manos de Clutter, que es una librería aparte y sin más relación con GTK+ que el hecho de usar GLib/GObject. ¿Y cómo se integran ambas? Se utiliza el renderizado "offscreen" para que GTK+ dibuje sus cosas en un buffer de memoria, Clutter coge esos buffers y los manipula como se le antoja (que ambas librerías no están muy integradas se comprueba en que puede hacer lo mismo con widgets QT). Un servidor no encuentra mucho sentido a esta división, y se pregunta por qué no se integran Clutter y GTK+ como Dios manda, o por qué GTK+ no desarrolla su propio sistema. Pero de momento la simbiosis entre ambos proyectos parece funcionar bien.