Archivo por meses: abril 2009

Llega GtkBuilder

Actualizado. Acabo de terminar una nueva versión de DeVeDe; sin embargo no os abalanceis como locos a por ella porque todavía no está disponible. La razón es que uno de los (pocos) cambios que hice fue migrar el código a GtkBuilder; el problema es que varias de las funcionalidades que aporta se han añadido en la nueva GTK 2.16, la cual viene en Ubuntu 9.04, la cual no sale oficialmente hasta mañana. Eso significa que si saco ahora esta nueva versión, nadie podrá usarla a menos que (como yo) instale una versión Release Candidate de Ubuntu. Por esa razón no la sacaré hasta el sábado (por aquello de dar tiempo a la gente a que migre de manera calmada y ordenada).

Sin embargo, aprovecho para escribir una breve introducción a GtkBuilder (breve porque tampoco hay mucho que explicar, es muy sencilla de usar).

¿Qué es GtkBuilder?

GtkBuilder es una biblioteca que llevará a cabo las mismas funciones que actualmente realiza LibGlade: a partir de una serie de ficheros XML creados con Glade u otro editor, generará las ventanas de una aplicación, incluyendo todos sus widgets internos.

¿Pero si va a hacer las mismas funciones, por qué sacar una nueva biblioteca en lugar de seguir con la vieja?

Por una razón muy simple: LibGlade no forma parte de GTK, sino que sigue un desarrollo completamente independiente. Eso la limita en algunos aspectos (por ejemplo, velocidad a la hora de soportar nuevos widgets y propiedades). Por otro lado, no tenía sentido que una biblioteca tan fundamental fuese un elemento externo. Por último, aunque LibGlade siempre funcionó muy bien y está bien implementada, había algunas cosas que se podían mejorar.

Por todo ésto los desarrolladores de GTK decidieron crear una biblioteca integrada en GTK y que fuese lo más parecida posible a LibGlade, con el objetivo de reemplazarla: GtkBuilder había nacido.

Trabajando con GtkBuilder

La forma de trabajar con GtkBuilder es muy similar a LibGlade. La principal diferencia es que en GtkBuilder no es posible generar sólo una parte del árbol (aunque se están planteando el soportar esta opción). Esto significa que es más eficiente poner cada ventana en un fichero XML independiente.

Si ya tienes un fichero .glade puedes convertirlo fácilmente al nuevo formato usando el script gtk-builder-convert. Como primer parámetro recibe el fichero .glade a convertir; como segundo parámetro, el fichero de salida en formato GtkBuilder; por último, opcionalmente se le puede pasar un parámetro -r seguido del identificador de un widget (usualmente una ventana), de manera que sólo convertirá dicho widget y todos sus hijos. Esta última opción permite separar una antigua interfaz Glade con todas las ventanas en un único fichero, en varios ficheros GtkBuilder, cada uno con una sola ventana.

Un ejemplo: gtk-builder-convert viejo_proyecto.glade ventana_ppal.ui -r main_win creará un fichero ventana_ppal.ui que contendrá la ventana main_win y todos sus elementos, del proyecto viejo_proyecto.glade.

Por cierto, la extensión de los nuevos archivos es .ui. Es un detalle que me costó encontrar.

La primera gran diferencia con Glade es que no hace falta importar ningún módulo, pues ya está dentro de GTK.

Trabajar con GtkBuilder es tan sencillo como:

class MiClase:
    __init__(self):
        builder=gtk.Builder()
        builder.set_translation_domain("mi_aplicacion")
        builder.add_from_file("path/to/file.ui")
        builder.connect_signals(self)
        ventana=builder.get_object("nombre_ventana")

En la primera línea creamos un objeto de tipo GtkBuilder; en la segunda especificamos cual es el nombre de nuestra aplicación de cara a usar GETTEXT para las locales; a continuación le indicamos qué fichero .ui contiene la definición de la interfaz que queremos generar. Estas tres líneas reemplazan a la única línea que utilizábamos con LibGlade.

En la siguiente línea le indicamos que conecte las señales con los métodos de nuestra clase; es igual que el método signal_autoconnect de LibGlade.

Por último, pedimos una referencia a un objeto concreto; es igual que el viejo método get_widget de LibGlade.

Trabajando con Glade

Las nuevas versiones de Glade-3 no sólo soportan el nuevo formato, sino que incluso trabajan por defecto en él. En general se sigue trabajando exactamente igual que antes; la única diferencia es que es recomendable que cada ventana vaya en un fichero (y, por tanto, en un proyecto) diferente.

Un detalle muy interesante es la comprobación del soporte de versiones de GTK en el nuevo Glade: si tenemos abierta una interfaz y escogemos Editar->Preferencias, nos saldrá el siguiente cuadro de diálogo:

glade

En la parte inferior vemos la opción Versiones de los toolkit necesarias. Dicha opción nos permite comprobar si en esta interfaz estamos usando algun widget que no esté soportado por alguna versión antigua de GTK o de GtkBuilder. Esto es precisamente lo que me ocurrió con esta versión de DeVeDe: el nuevo constructor de menús sólo está soportado a partir de GTK 2.16, que viene a partir de Ubuntu 9.04.

En otra entrada explicaré como se trabaja con las GtkComboBox y sus listas asociadas, pues GtkBuilder permite generar todo desde Glade, sin necesidad de picar apenas código.

Asus y Linux, no tan amigos

A veces estás tan ilusionado con algo que, cuando menos te lo esperas, te llevas un batacazo de los gordos por confiarte demasiado.

Esto es lo que me ha ocurrido estas navidades con Asus. Después del apoyo que dio a Linux con el EEEPC y con tecnologías como Express Gate, lo último que me esperaba era encontrarme con que un portátil suyo diese, bajo Linux, una serie de problemas muy serios. El modelo en cuestión es el Asus F5GL.

¿Qué es lo que ocurre? Todo parece apuntar a que las tablas ACPI de la BIOS contienen errores, y por eso no funcionan cosas tan básicas como que el ordenador se apague cuando finalizas la sesión (hay que apagarlo «a mano» manteniendo pulsado el botón durante cuatro segundos). Y ya ni hablo de funcionalidades más «avanzadas» como el indicador del nivel de las baterías, o las teclas específicas para control de volumen, brillo… las cuales, obviamente, tampoco funcionan.

La razón de este fallo parece venir del hecho de que han usado un compilador de Microsoft para crear dichas tablas. Tal y como podemos leer en http://forums.gentoo.org/viewtopic.php?t=122145, el compilador de ACPI de Microsoft «tolera» una serie de errores en el código. Dichos errores incumplen el estándar ACPI, y de hecho ese código nunca compilaría en el compilador oficial de Intel (que sigue el estándar punto por punto). «Casualmente», el intérprete ACPI de Windows tolera perfectamente dichos errores, mientras que el interprete de Linux (que intenta seguir al pie de la letra el estándar ACPI, como debe ser), no. Que el lector saque sus propias conclusiones.

Lo peor de todo es que, tras explicárselo al servicio on-line de ASUS, su respuesta fue, literalmente, que ese no era un fallo suyo, y que era responsabilidad de mi distribuidor de Linux el resolver ese problema. Personalmente no estoy de acuerdo: creo que si una empresa saca un equipo del que afirman que cumple el estándar ACPI, pero sus tablas contienen errores no permitidos por dicho estándar, la culpa es de ellos. Intenté insistir y su segunda respuesta fue un simple close! (literalmente).

Tras rebuscar por Internet encontré la página de LinLap.com sobre el F5GL (para los que no la conozcan, dicha página informa sobre la compatibilidad de los portátiles y Linux), y allí se comentaban todas y cada una de mis desdichas. Sin embargo, comentaban también dos detalles interesantes:

  • Con la última KNOPPIX (5.1.1, del 1 de abril de 2007) el apagado funcionaba perfectamente.
  • Había un parche en http://patchwork.kernel.org/patch/1478/ para el kernel 2.6.27 (el que lleva Ubuntu 8.10) que pasaba de los errores en las tablas y hacía que las funciones ACPI funcionase de nuevo.

Revisé el código de todos los núcleos (el de la KNOPPIX, el actual y el parche) y llegué a la conclusión de que dicho parche era un rodeo que ya había para este problema, pero que por alguna razón fue eliminado.

Un par de meses después de encontrar todo esto salió el núcleo 2.6.29, incluyendo un rodeo mucho más depurado para este problema (en concreto, el código es específico para ASUS). Por desgracia, Ubuntu 9.04 llevará el núcleo 2.6.28, el cual todavía no incluye dicho parche. Quien sí trae el nuevo núcleo es Fedora 11 (aún beta, no saldrá hasta el 26 de mayo de 2009), y de hecho la he probado usando un Live-CD y todo parece funcionar perfectamente. Por desgracia el portátil es de un colega y no me atrevo a meterle esta distribución, principalmente porque ya está muy acostumbrado a usar APT.

¿Qué soluciones hay? La más inmediata creo que será, cuando salga Ubuntu 9.04, instalar el núcleo de la versión de desarrollo 9.10 usando pinning. La segunda, que puede que funcione o puede que no, es pedir a los empaquetadores de Ubuntu que hagan un backport del parche del 2.6.29 al 2.6.28, en la página https://bugs.launchpad.net/ubuntu/+source/linux/+bug/333064. Con suerte lo añaden y en un mes estos portátiles vuelven a funcionar al 100%. La tercera, más complicada (sobre todo por los drivers extra de la tarjeta de vídeo e inalámbrica) es compilar yo mismo el núcleo 2.6.29.

Y para terminar, un consejo para todos aquellos que se vayan a comprar un portátil al que pretendan instalar Linux: pasaos antes por http://www.linlap.com y aseguraos de que el modelo que habeis escogido no da problemas. Os ahorrareis muchos disgustos.

Buscando en el baúl de los recuerdos

Hoy me llegó un mensaje de un usuario que estaba portando FBZX nada menos que a OS/2. Y como no podía ser, me entró la morriña, porque yo fuí un Warper en mis tiempos mozos.

Manual de OS/2
Manual de OS/2

Esta es nada menos que la portada del manual de uso de mi OS/2 Warp 3.0, que tengo original y correctamente registrado (me había costado 5.000 pesetajas en el 96).

Pero lo que más me sorprende es que todavía estén mis mensajes y la captura de mi viejo escritorio en la lista TeamOS/2 españa. También encontré la vieja revista EDM2, que trataba sobre OS/2 y traía un montón de artículos sobre como programar con él. Y los comentarios sobre WarpGlobe, y Radio Maceda BBS,…

Pero como siempre, todo llega a su fin: las últimas declaraciones de IBM sobre el futuro de OS/2 dejaban ver a las claras que lo iba a dejar en la cuneta (como, en cierto modo, fue). Esa fue la razón de abandonarlo y pasarme a Linux. Visto en retrospectiva, fue una decisión muy acertada.

Actualizado: Incluso encontré mi mensaje de despedida en la lista de TeamOS2 España. Dentro de poco hará 10 años que me pasé oficialmente a Linux.