What's this all about? To start from the beginning, about Python. Although we are focusing here on PyGTK (especially because starting from Gnome 3 inclusive, it won't continue its development, so that means "renew or die"), this is about porting applications done with intermediate libs that work with GObject (gtk, gdk, webkit...) to GObject Introspection. So what's going to be told on this post is also valid for this other API's.

What's GObject Introspection (link and sublinks are recommended readings)? As can be read from the description from the web and the Debian package itself, it is a project for providing machine readable introspection data of the API of C libraries.

What is this for? It has many applications, such as automatic code generation for bindings (the most interesting one), API verification and documentation generation. About the most important point, we don't need anymore the bindings that we have been using so far (because the metadata that the bindings had are now stored directly in GObject), so it is one layer less of conflict and we can now access GObject libraries directly. This also allows us to make multi-language applications between languages from different levels (in instance, C and Python, Java... and even Javascript).

¿De qué va esto? Para empezar, de Python. Aunque aquí nos centraremos en PyGTK (sobretodo porque no continuará su desarrollo a partir de Gnome 3 inclusive y esto significa renovarse o morir), esto va acerca de portar aplicaciones hechas con librerias intermedias que operan contra GObject (gtk, gdk, webkit...) a GObject Introspection, así que esto también es válido para estas otras API's.

¿Qué es GObject Introspection (enlace y subenlaces de lectura recomendada)? Como reza la propia descripción de la web y del paquete de Debian, es un proyecto que pretende proveer datos de introspección del API de las librerias de C legibles por la computadora.

¿Para qué sirve? Tiene diversas aplicaciones, tales como generación automática de código para bindings (la más interesante), verificación de la API y generación de documentación. Acerca del punto más importante, nos quitamos de en medio los bindings que hemos estado usando hasta ahora (porque los metadatos que tenian los bindings ahora se almacenan directamente en GObject), así que es una capa menos de conflicto y ahora podemos acceder directamente a las librerias de GObject. Asimismo, esto nos permite hacer aplicaciones multi-lenguage entre lenguages de distintos niveles (por ejemplo, C y Python, Java... e incluso Javascript).

Para quién no lo sepa y a modo de entradilla, comentar que Naufrago! es un lector offline simple de RSS (incluyendo imágenes) escrito en PyGTK.

Resúmen del bagaje

Haciendo una memoria sintética de aquello con lo que he lidiado en esta versión, decir que he intentado usar correctamente el tema de los threads (hilos), además de añadir otros para alguna que otra tarea que dificultaba el refresco de la interfaz gráfica (p.ej. la de importación de feeds). También me estuve dando cabezazos con el tema del recuento de las entradas no leídas, empezando por un tratamiento de los nombres de feed a nivel de parseo para hacer el cálculo de restantes, y terminando por gestionarlo a través de consultas SQL (que es menos complicado y encima más rápido). En este aspecto, acabé reduciendo bastantes lineas de código de una larga y espesa función. Y ya en la línea más de lo estético, varias opciones (con su reflejo en el diálogo de preferencias) para modificar temas del aspecto de la aplicación (toolbar, tray/statusicon, feeds leídos...).

Un día voy a lanzar lighttp y me encuentro con lo siguiente:

Starting web server: lighttpd/usr/sbin/lighttpd: Symbol `FamErrlist' has different size in shared object, consider re-linking
2010-09-01 17:25:05: (network.c.345) can't bind to port: :: 80 Address already in use failed!

Primer error: no es un error, sino un warning por usar gamin en vez de fam. En definitiva, esto no afecta al correcto funcionamiento de la aplicación (Debian bug #521274).

Segundo error: efectivamente en el puerto 80 no hay nada, así que no parece un mensaje de error muy acertado. El problema vino por poner el módulo ipv6 en /etc/modprobe.d/blacklist.conf y tener el binario de lighty compilado con soporte para IPv6 (lighttp -V | grep -i ipv6). Entonces tenemos 2 opciones: volver a dejarlo como estaba (cargando pues dicho módulo quitándolo de la blacklist), o bien tocar la configuración de lighty para que no intente usarlo. Para esto último, con comentar (anteponiendo un #) la linea con lo siguiente es suficiente:

 include_shell "/usr/share/lighttpd/use-ipv6.pl"

Y finito (Debian bug #471388). My 5¢!