Pasando ya a describir los cambios, en SuperShow apliqué varios parches que me envió Pablo Rodríguez. Para empezar, cambió los botones originales, hechos con mapas de bits, por botones vectoriales, con lo que la apariencia de éstos ha mejorado muchísimo. Por otro lado, añadió dos botones extra que permiten saltar directamente a la siguiente diapositiva o a la anterior, complementando a los que permiten avanzar o retroceder la presentación cinco segundos. Por último, también retocó el icono del programa y lo añadió a la ventana de Acerca de y a la barra superior del resto de ventanas. Por mi parte, corregí un pequeño bug que había al volver a reproducir una presentación con el botón correspondiente: al pulsarlo saltaba a la segunda diapositiva en lugar de a la primera.

En el tintero se han quedado dos añadidos muy interesantes. El primero es un contador de tiempos y de diapositivas. Las razones para no ponerlo han sido dos:

• Para empezar,  el texto aparece algo cortado por la parte superior; Pablo aún no sabe por qué.
• Por otro lado, la versión actual de SWFC (el compilador de FLASH que usa SuperShow) no soporta añadir sólo un subconjunto de símbolos de una fuente de letras, sino que hay que meter absolutamente todos los que están disponibles en el fichero TrueType, con lo que el tamaño de las presentaciones se dispara. Esto está corregido en la versión de desarrollo, por lo que pronto deberíamos poder incluirlo.

El otro añadido es cambiar el código de renderizado de las diapositivas para que use LibPoppler. La principal razón de no haberlo hecho es que no he conseguido compilar PyPoppler en mi sistema. Cuando esté completamente recuperado me pondré con ello.

Un detalle bastante triste es que se ha perdido la compatibilidad con Gnash. Hicieron algún cambio en el código justo antes de sacar la actual versión estable, y el resultado es que los métodos getDuration y getPosition no funcionan cuando se usa Gstreamer como backend (sí funcionan si se usa SDL). Ya avisé del error y espero que lo corrijan pronto.

Respecto a DeVeDe, había un fallo en la traducción a catalán que hacía que no arrancase cuando se usa esa lengua en el sistema. El traductor me envió un nuevo fichero .po que lo corrige. También apliqué una serie de parches que me envió Peter Gill para la versión de Windows (en Linux funciona bien). Por otro lado, si se cerraba la ventana inicial (la que pregunta el tipo de disco que se quiere crear) ésta desaparecía, pero el programa no se cerraba porque me había olvidado de añadir un callback. Ahora pregunta si queremos salir. Por último, hice un par de cambios en el cálculo de la tasa mínima de vídeo (por sugerencia de otro usuario), de manera que el tamaño final de la imagen de CD/DVD se acerca más al estimado por DeVeDe en la ventana principal.

Nota: ésta entrada la escribí el 17 de abril, pero por despiste la mandé a borradores en lugar de publicarla.

Precisamente es FBZX el programa que más me preocupa en estos momentos (dejando de lado los serios problemas de GTKpsProc), pues el emulador de Z80 que lleva, escrito por Marat Fayzullin, no es GPL. Por desgracia no es fácil sustituirlo por otro. Estoy evaluando la dificultad de escribir uno nuevo (tarea árdua pero no imposible) o intentar adaptar alguno extraído de BlueMSX u OpenMSX. Esta última opción parece la más sencilla a priori, pero en la práctica hay muchos cambios que hacer, así que tendré que evaluarlo con calma.

Respecto a DeVeDe los cambios son mínimos: nuevas lenguas, corrección de un par de pequeños bugs, y el añadido de dos comandos extra en la conversión: CGOP y SC_THRESOLD. Estos hacen que los GOPs estén siempre cerrados y midan siempre lo mismo, lo que debería aumentar la compatibilidad con viejos reproductores.

Y la primera cosa que tengo que añadir en la próxima versión será el poder mezclar vídeos con diferentes relaciones de aspecto en el mismo disco. En efecto, a última hora de ayer descubrí que si se mete un vídeo con relación de aspecto clásica (4:3) en el mismo título que un vídeo WideScreen (16:9), ambos se verán con el mismo aspecto. Se trata de una limitación del estándar DVD. La solución consiste en meterlos en titlesets diferentes. Por desgracia, no es posible saltar directamente de un titleset a otro, por lo que implementarlo directamente en DeVeDe rompería la posibilidad de saltar de un título al siguiente, o al anterior, etc.

Una solución que probé fue añadir la opción jumppad en el XML de DVDAuthor. Esa opción añade automáticamente algo de código que permite saltar desde cualquier parte del DVD a cualquier parte, sin las limitaciones del estándar. Funcionaba bien, pero para asegurarme rebusqué en google y descubrí que, en ciertos casos, puede romper la compatibilidad con algunos reproductores. En la misma página se explicaban algunos métodos para conseguir lo mismo “manualmente” (básicamente, añadir un menú virtual con una función que salte al título que se le pase en un registro). Por desgracia es algo demasiado complejo como para implementar sin haberlo probado exhaustivamente, así que no irá hasta la próxima versión.

Otros cambios que quiero añadir son, por ejemplo, el soporte de matrices de codificación alternativas, permitir múltiples subtítulos, o poder elegir la pista de audio que se desee cuando el video original tiene varias.

Hace unos días, mientras ultimaba la nueva versión de DeVeDe, encontré un molesto bug en el widget Gtk.FileChooserButton; en concreto en el método set_filename(). Cuando el usuario pulsa el botón Propiedades para cambiar las propiedades de una película (tasa binaria, resolución…), uso ese método para rellenar dicho FileChooserButton con la ruta completa del archivo correspondiente; sin embargo, a veces (no siempre) fallaba, quedando el widget vacío. Tras hacer varias pruebas llegué a la conclusión de que era totalmente aleatorio: no dependía de la longitud del nombre, ni del directorio en que se encontrase, ni del número de niveles… el mismo archivo a veces aparecía correctamente en el widget y otras veces no. Con Ubuntu 7.04 (que usa GTK 2.10) dicho fallo no ocurría (que yo recordase, al menos).

Dado que no tenía claro si el error estaba en GTK o en los bindings para Python (PyGTK), durante el fin de semana hice un pequeño programa de prueba en C. El resultado es que, efectivamente, el error es de GTK. Además probé el mismo código en una Ubuntu 7.04 y, tal y como sospechaba, no falla (por lo que vi en la lista de cambios de GTK 2.10 a 2.12, los desarrolladores hicieron muchas mejoras en la clase FileChooser). El problema realmente gordo es que todos los intentos por esquivar el problema han fallado, lo que significa que mientras no lo corrijan, DeVeDe no funcionará correctamente :(

De momento he notificado el bug y he añadido una nota en la FAQ de DeVeDe. Mañana o pasado (cuando la cabeza deje de darme vueltas) publicaré la nueva versión.

Otra cosa que he descubierto es que el PPD para impresora PostScript genérica creado por FooMatic no pasa la prueba de cupstestppd. Parece que no le gusta que se especifique un parámetro por defecto con el nombre default.

Y por último, parece que python-fam no funciona bien con Python 2.5 en algunos equipos, así que he decidido sustituirlo por python-gamin, que se supone que es lo que se usa hoy en día.

De todas maneras, el código actual de GtkPSproc está demasiado sucio, así que estoy considerando reescribirlo en condiciones (en python, por supuesto), igual que he hecho con DeVeDe. De momento estoy rehaciendo la interfaz con Glade-3, porque no se que ocurre que si cargo el fichero XML de la vieja interfaz (creado con Glade-2) y modifico cualquier cosa, dejan de funcionar los eventos en el programa, como si no ejecutase el signal_autoconnect(). Supongo que será alguna incompatibilidad rara, no se.

Y ya que hablo de DeVeDe, hay noticia: en cuanto reciba los tres ficheros de traducciones que faltan lanzaré la versión 3.4, con soporte completo de sonido 5.1, aunque la verdadera novedad de esta versión es que, por fin, terminé de refactorizar todo el código y ahora ya se puede mirar para él sin sentir verguenza ajena; y lo que es más importante: ahora es extremadamente fácil añadir nuevas opciones de codificación. Espero que en las nuevas versiones se empiece a notar ésto.

Lo increible es que no me lo comunicaron hasta ayer, cuando esa versión tiene casi un año…

No tiene sentido que comente nada cuando ya lo dicen mucho mejor que yo sitios como Barrapunto o Kriptópolis.

Lo primero es poner el selector del GtkTreeView en modo de selección múltiple:

treeview.get_selection().set_mode(gtk.SELECTION_MULTIPLE)

Ahora ya podremos marcar más de una fila simultáneamente usando las teclas Mayúsculas y Control.

Leer los elementos marcados es tan sencillo como obtener primero el iterador y el arbol:

tree,iter = self.z88tree.get_selection().get_selected_rows()

Si el iterador es None, no hay ninguna fila seleccionada, pero si lo está, no tenemos más que recorrer los elementos del iterador para acceder a las filas. Con ellas, podemos usar el método get_value del arbol para obtener el valor de cada una.

En este ejemplo almacenamos en la lista ret el valor de la columna cero de cada fila seleccionada:

ret = []
for item in iter:
ret.append(tree.get_value(tree.get_iter(item),0))

Fácil, fácil, para toda la familia.

Sin embargo, por dentro los cambios son mucho más radicales, pues prácticamente he reescrito la aplicación. Las razones han sido tres:

• Por un lado, varias partes del código estaban muy sucias y eran muy poco modulares.
• Por otra, quería internacionalizar la aplicación, para poder traducirla a otros idiomas (aunque en esta versión todavía no hay traducciones).
• Por último, quería organizar en condiciones el código de las ventanas poniendo los manejadores de eventos de cada una en su propia clase (haciéndolo así más modular mantenible), además de simplificarlo usando diálogos para los distintos mensajes que pueden aparecer, en lugar de ventanas modales.

La última razón es especialmente importante. En el caso de SuperShow, el código era ya bastante bueno pues es la última aplicación que he escrito hasta la fecha, pero en el caso de Z88Transfer el código era realmente sucio, pues fue la primera aplicación que hice con PyGTK. Sin embargo, gracias a que es una aplicación relativamente sencilla, el código aún era razonable (la transferencia de ficheros y la conversión de formatos van en sendas clases separadas, lo que simplificó la reescritura).

¿Y a qué viene ésto? Pues viene porque también estoy reescribiendo el código de DeVeDe. Cuando comencé a escribir con PyGTK no sabía como generar una única ventana ni como conectar los eventos de ésta con métodos de una clase, pues la documentación del módulo PyGlade era escasa, por no decir nula. El resultado fue que la única manera que tenía de programar era generando una instancia de absolutamente todas las ventanas disponibles en el archivo de Glade, y metiendo todas las funciones de eventos directamente en un único fichero, lo que dio lugar a un código… bueno, llamémoslo caótico (por ser benévolo conmigo mismo), y muy poco mantenible.

Ahora lo veo en retrospectiva y me parece increible que haya sido capaz de escalar el código original de DeVeDe hasta el nivel actual, aunque siendo yo el programador supongo que no tiene mucho mérito. El que sí que tiene mérito es, sin duda, Peter Gill, que lo revisó y modificó para que funcionase también en windows. Un código que fue escrito originalmente como una solución chapucera y rápida para hacerle con comodidad a mi madre una pequeña colección de DVDs con los programas de Arguiñano que bajaba de la mula.

En estos momentos ya he reescrito toda la parte de conversión de vídeos y de generación de la imagen de DVD usando una orientación a objetos bastante razonable, y posiblemente lance una versión sólo con esas modificaciones, pues el nuevo código debería ser mucho más resistente a fallos tontos (el propio Peter, cuando lo revisó para asegurarse de que funcionase en Windows, comentó que sería una tarea muchísimo más sencilla gracias a la nueva arquitectura). El siguiente paso será cambiar a una clase independiente todo el código de la ventana de propiedades de los vídeos, para permitir añadir con más facilidad nuevas opciones de codificación. Por último, meteré en su propia clase la ventana principal y pondré la ventana de selección de tipo de disco como un diálogo. Entonces podré dar por terminada la refactorización del código y seguir añadiendo cosas nuevas.

En el verano de paso de EGB a BUP, mis padres decidieron elevar el tejado y dividir con tabiques el desván, de manera que cada uno pasó a tener su propio cuarto de trabajo y juegos. Al principio ni siguiera tenía luz, y fui yo el encargado de poner una instalación provisional… instalación que, con pequeños cambios, dura hasta hoy (como todas las cosas provisionales de este país). Fue en este maravilloso nuevo desván donde monté mi primer taller.

Aproveché un mueble de la vieja cocina para poder meter mis (bueno, de mi hermano) revistas de electrónica, y monté una estantería y tres mesas para poder trabajar y poner más cosas. Poco a poco fui almacenando motores, radios viejas, piezas de televisores… En mi taller monté los múltiples teclados mecánicos para mi Spectrum, junto con muchos otros circuitos también para él; ensamblé mi primer PC con piezas de segunda mano, programé mis primeras aplicaciones, construí mis cajas de modding…

Cuando me independicé no me llevé nada de mi taller. En el fondo era un nexo de unión. Saber que sus metros de cable, sus cientos de circuitos impresos, sus viejas placas de 386, sus altavoces y sus motores extraidos de viejos juguetes seguian allí me tranquilizaba. Era un poco como sentir que, si algún día tenía que volver a casa de mis padres, todavía estaría esperándome exáctamente igual que como lo dejé.

Hoy, sin embargo, he tenido que hacer limpieza. Mis padres quieren revestir las paredes (aún estaban “en ladrillos”), poner una instalación eléctrica en condiciones y adecentarlo todo. Y ha sido duro. Ha sido como tirar dieciocho años de recuerdos a la basura.

Al principio iba a tirar sólo aquellas cosas que, real y objetivamente, ya no servían para nada, pero al final se ha ido casi todo al cubo. Intento convencerme de que era algo que tenía que hacerse, pues desde que me fuí de casa ya casi no pasaba por allí y se estaba convirtiendo en un almacén de basura; pero aún así…

Estas son dos fotos que saqué con el móvil, después de limpiar buena parte del material.

Adiós, y gracias por darme tan buenos momentos.