Como habreis notado, la web, el blog y mi correo han estado caídos durante una semana entera por culpa de una mudanza de mi hoster. Afortunadamente parece que ya vuelve a funcionar todo, así que aprovecharé para sacar una copia de seguridad de las entradas (que los servidores los carga el diablo }:-)
Más problemas con los espacios en blanco en DeVeDe
He tenido que sacar la versión 2.5 de DeVeDe rápidamente para corregir un nuevo error con ficheros o directorios que contienen espacios en blanco. Cuando se marcaba un fichero con la opción «Este fichero ya está en un formato MPEG-PS adecuado para discos DVD/xCD», no añadía comillas en el path al crear el enlace o al intentar borrar ficheros viejos con el mismo nombre, por lo que fallaba si había algún espacio en medio.
También corregí otro problema al borrar ficheros temporales: hacía un rm -rf «path/nombre_??_??.mpg» para borrar todos los ficheros temporales de películas, con comillas para que funcione también si hay espacios en el path o el nombre de fichero. Desgraciadamente no tuve en cuenta que, por culpa de las comillas, bash lo toma de manera literal y no expande los comodines, con lo que intenta borrar el fichero nombre_??_??.mpg en lugar de «todos los ficheros que cumplan esa regla».
¡¡¡¡¡Pena de muerte para los que usan espacios en los nombres de fichero!!!!!
Programando para Windows Mobile 5 con Mono (parte 2)
Ahora que ya establecimos contacto entre la PDA y el PC podemos empezar la parte de programación.
Windows Mobile 5 incorpora una máquina virtual de .NET, por lo que, en principio, parece que podemos utilizar Mono directamente para escribir un programa, transferir el .exe directamente a la PDA y ejecutarlo. Por desgracia la cosa no es tan sencilla, pues las PDAs disponen de una versión reducida de .NET denominada .NET Compact Framework. Se trata, básicamente, de un subconjunto de la máquina virtual clásica, por lo que hay una serie de clases y métodos que no estarán disponibles. Es por esta razón que los ejecutables .NET para PDAs usan una firma digital diferente que los que son para equipos clásicos, y por eso si intentamos ejecutar en una PDA un programa hecho con Mono recibiremos un mensaje de error, indicándonos que ese fichero no es un programa válido.
Afortunadamente, Jean-Baptiste Evain publicó en su blog un programa que cambia la firma de un ejecutable .NET, de manera que ya puede correr en una máquina con Compact Framework (por supuesto, deja de ser ejecutable en un equipo clásico). Con ésto ya tenemos salvado el principal escollo, aunque hay que tener en cuenta que, para usarlo, es necesaria la versión 0.4 o posterior de CECIL, un módulo escrito y mantenido por el propio Jean-Baptiste Evain que da acceso a bajo nivel a los ficheros .exe de .NET. En Debian testing y en Ubuntu Edgy está dicha versión, pero en Ubuntu Dapper, que todavía es la versión estable de Ubuntu, está la versión 0.3. De todas maneras, si tenemos en cuenta que Edgy saldrá el próximo día 10, no es una espera demasiado larga.
Para usar este programa tan sólo tenemos que compilarlo con Mono y luego llamarlo desde la línea de comandos, poniendo como primer parámetro el fichero .exe que queremos convertir.
Ahora que ya podemos meter código ejecutable en nuestra PDA debemos saber que hay algunas diferencias a la hora de programar para ésta, las cuales vienen dadas por la diferente naturaleza del dispositivo (sin teclado, poca memoria, sin ventanas que se solapan…). Veamos algunas de ellas.
Para empezar está el tema de ventanas y widgets. Para trabajar con ellas usaremos las WinForms, pero teniendo en cuenta que algunos widgets (como, por ejemplo, RichTextForm) no estarán disponibles. En esta página de microsoft (en castellano, además) hay una excelente relación de las diferencias entre .NET Framework y .NET Compact Framework.
Existen, sin embargo, un par de detalles extra que me gustaría comentar. Para empezar, por defecto no aparece el botón para desplegar el teclado virtual. Para disponer de él tenemos que añadir a nuestro Form un menú, de la siguiente manera:
MiForm.Menu = new MainMenu();
(siendo MiForm el objeto formulario al que le queremos añadir el menú y el teclado). En esta página podemos encontrar más detalles sobre el teclado virtual. OJO: aunque en ella dice que dicho menú se añade automáticamente, ésto sólo es cierto cuando trabajamos con Visual Studio, no con Mono.
La segunda cuestión se refiere al botón de la ventana con forma de X. La primera impresión que da es que dicho botón destruye el Form; sin embargo, lo que hace realmente es minimizarlo. Tal y como se explica en esta página de Microsoft sobre el botón de los formularios, para que el botón destruya el Form es necesario hacer lo siguiente:
MiForm.ControlBox = True MiForm.MinimizeBox = False
aunque, en las pruebas que hice, parece que basta con poner a False la propiedad MinimizeBox únicamente, sin tocar ControlBox. Por último, si ponemos ambas a False el Form no tendrá ningún botón.
Un detalle importante es que cuando cerramos el último formulario la aplicación se cierra. En la plataforma clásica, sin embargo, al cerrar un formulario simplemente se retorna de Application.Run(formulario). Esto lo descubrí de casualidad, porque, en la aplicación que estoy haciendo, necesito cambiar por completo los widgets del formulario en función de las acciones del usuario. Al principio destruía el formulario actual (llamando a su método close()) y creaba uno nuevo, pero si bien funcionaba en la plataforma clásica, no lo hacía en la PDA. La solución en este caso fue llamar al método Clear() del formulario, que elimina todos los widgets de éste y lo deja listo para ser repoblado con nuevos elementos.
Comentar también que si la PDA nos devuelve un error indicando que necesitamos una versión posterior de .NET para ejecutar dicho programa, significa que hemos usado alguna clase o método no soportado en el Compact Framework. Al pulsar en OK podremos ver el error completo, y en concreto qué método o clase es la que provocó el error. Si nos ocurre ésto tendremos que buscar la manera de sustituir dicha clase o método por otro que sí esté soportado.
Esto es todo lo que llevo descubierto hasta ahora. A medida que encuentre nuevas cosas interesantes las iré poniendo por aquí.
Por último, añadir dos URLs con información extra (en inglés) sobre el .NET Compact Framework.
Sabor a 8 bits
Hace muchos años, cuando aún usaba regularmente mi querido Spectrum, conocí un juego que me impactó: Elite. El juego fue uno de los primeros -si no el primero- en usar gráficos en tres dimensiones para las partes del espacio. Por supuesto eran gráficos simples, formados únicamente por líneas, sin texturas en las caras, pero utilizaba un algoritmo (bastante simple) para borrar las caras posteriores, lo que producía la ilusión de que las naves y estaciones eran sólidas.
¿Y a qué viene ésto? Pues a que hace unos días encontré Oolite, un clon del Elite original escrito en Objective C y que utiliza OpenGL para la parte gráfica.
La mecánica del juego es la misma: comprar barato en una estación espacial, vender caro en otra, y en el viaje entre ambas defenderte de las naves que te ataquen, al más puro estilo arcade. Al igual que en el juego original también se puede vivir del contrabando, de la minería de asteroides, o directamente del saqueo. La gran diferencia, aparte de los gráficos mejorados, es que los enemigos son más listos que antes, y ahora, además, el universo ya no gira en torno a tí, sino que te puedes encontrar con grupos de mercaderes que van a su bola, policía galáctica más atenta a lo que les ocurre a otras naves, grupos organizados de piratas que lo mismo te atacan a tí como a otros…
El resultado es una gran recreación del juego original, pero actualizado a los nuevos tiempos. Aunque no es el primer intento: hace un año ya había encontrado Elite – The new kind. Este programa fue creado directamente a partir del código original del juego para el BBC modelo B, aunque luego se le añadieron algunas mejoras visuales, como por ejemplo gráficos con caras coloreadas, lo que hacía que las naves fuesen realmente sólidas. Sin embargo esa versión no me acabó de enganchar, en buena parte porque de aquella no tenía joystick, y controlar una nave como ésta desde teclado no es sencillo.
Programando para Windows Mobile 5 con Mono
La política no es la única que hace extraños compañeros de cama: en estos momentos estoy compartiendo mi vida con una PDA con Windows Mobile 5.
La razón es que, por motivos laborales, tengo que escribir un programa para dicho sistema operativo, y aunque los entornos de desarrollo de Micro$oft son conocidos por su gran calidad, la idea de cambiar mi escritorio del trabajo a Windows (con todo lo que ello conlleva: configurar de nuevo el programa de correo, enlaces del navegador, etc) me tiraba mucho para atrás. Por eso decidí realizar el programa con .NET, para lo cual podría usar Mono y MonoDevelop desde GNU/Linux. Además podría vender la moto de que el mismo programa también les funcionará en GNU/Linux…
Por supuesto, las cosas no fueron sencillas. El primer problema era conseguir comunicar la PDA con Linux, problema que parecía resuelto con SynCe (y su Wiki de documentación). Tras un par de pruebas confirmé que el driver ipaq no reconocía a la PDA, así que me puse a bucear en la página de documentación para Windows Mobile 5 y descubrí que los procesadores Intel PXA27x todavía no están soportados por un fallo en su controlador USB.
Como no podía ser de otra manera, mi PDA tenía un procesador de esa familia, lo que reducía mis opciones a una: usar BlueTooth. Afortunadamente, en la documentación anterior se explica muy bien como configurarlo, aunque hay un par de detalles que no comentan bien y que hay que tener en cuenta:
- Para establecer la conexión no sirve el comando triggerconnection, sino que hay que lanzar ActiveSync y escoger Conectar por BlueTooth en el menú.
- Una vez conectado toda la comunicación se realiza a través del puerto 990 de TCP/IP, por lo que es necesario abrir en el firewall el acceso a nuestro equipo a través de la interfaz ppp0.
- De las dos direcciones IP especificadas en el fichero /etc/ppp/peers/dun, la primera es la que se le asigna a nuestro ordenador y la segunda la de la PDA.
- La misma conexión TCP/IP está disponible para otros programas, aunque en mi caso no puedo usar Internet Explorer para navegar porque se empeña en conectar de nuevo mediante alguno de los otros perfiles disponibles.
- Parece que no basta con añadir el servicio SP (serial port) para que aparezca el ActiveSync en la PDA, sino que también tiene que estar el servicio LAN y el DUN.
- Al contrario de lo que dice en la documentación para BlueTooth, hay que lanzar vdccm y no dccm. Además no hay que olvidarse de los parámetros que aparecen en Iniciando la conexión.
Añadir que hay un bug en la pila BlueTooth actual (la que traen Ubuntu Edgy y Debian testing/inestable) que desactiva el ISCAN nada más lanzar el servicio, por lo que el ordenador no aparecerá en la lista de dispositivos BlueTooth de la PDA. Para solucionarlo hay que añadir el comando discovto 0; en la sección device del fichero hcid.conf, y cada vez que se inicie la pila BlueTooth (al arrancar el ordenador o hacer un /etc/init.d/bluetooth restart) ejecutar el comando:
dbus-send --system --dest=org.bluez /org/bluez/hci0 org.bluez.Adapter.SetMode string:discoverable
para activar el ISCAN de nuevo. Podemos comprobar el estado con
hciconfig -a
Por último, para los usuarios de Ubuntu Dapper, añadir que la versión de SynCe que trae es demasiado antigua y no soporta Windows Mobile 5, así que es necesario bajarse los fuentes desde la página y recompilar.
La parte de como escribir programas para la PDA la dejo para una segunda entrada, que esta ya es demasiado larga.
GAG, amenazado por las patentes de software
Hace unos días recibí un correo-e, proveniente de la mismísima oficina europea de patentes, en el que me preguntaban la fecha en la que lancé GAG 1.0 y, a ser posible, el código fuente de dicha versión para comprobar si se podía considerar arte previo de una patente que estaban examinando. La patente en cuestión es, nada más y nada menos, que la de un gestor de arranque gráfico.
Tras el acojone inicial rebusqué en mis viejos CDs y molesté a varios colegas por teléfono hasta que por fin encontré el mensaje original, fechado el 12 de mayo de 1999… o sea, ocho meses después de la fecha de presentación de la solicitud de patente. Afortunadamente recordé que un colega (hola David) había creado otro gestor de arranque gráfico anterior a GAG. Se trata de MBRMenu y la versión 2.0 se había publicado en marzo de 1998 (en su página no indicaba la fecha de la versión 1.0, pero con esa era suficiente).
Respondí al correo con toda esta información y pedí que me informasen del estado de la patente. Al día siguiente recibí una respuesta dándome las gracias y explicándome que el proceso aún llevaría algunos años más (?). Esa respuesta me chocó bastante: si la solicitud de patente se había hecho hacía siete años ¿cuantos más iban a tardar en concederla? Empecé a considerar que se tratase de una broma, pero no pude encontrar nada raro en la cabecera del mensaje (parece que realmente vino del dominio epo.org), y el dominio espacenet.com parece que está registrado a nombre de la EPO también; además, el texto de la patente no son dos hojas precisamente, y tiene bastante pinta de legal… si es una broma se la han currado mucho. Y además ¿una broma de quien?
Pocas horas después, a raíz de una noticia sobre el registro de arte previo que quiere montar el OSDL, leí un texto en el que Richard Stallman afirmaba que si un revisor de patentes considera que un trabajo determinado no es arte previo, en un posterior juicio de patentes los jueces suelen no aceptar dicho trabajo como posible prueba para anularla, aunque el revisor estuviese bebido (o presionado para aprobar la patente) ese día. Por desgracia me enteré de esto bastante después de responder el mensaje, lo que significa que, quizás, les he dado la patente en bandeja de plata.
Definitivamente las patentes de software son una locura. Tenemos que hacer lo que sea para impedir que se aprueben en Europa, o el software libre pasará a la historia.
Nueva versión de DeVeDe
Inauguraré este blog con el anuncio de la nueva versión 2.4 de DeVeDe. Entre las principales novedades está el poder especificar que un fichero de vídeo ya está en formato MPEG-PS, con lo que DeVeDe no lo volverá a comprimir, sino que lo meterá tal cual en el disco. Esto es especialmente útil cuando capturas algo directamente de la televisión, pues no pierdes calidad.
Otra novedad es que ahora se puede escoger el algoritmo de MBD (MacroBlock Decission), con lo que se puede escoger entre mayor velocidad de conversión o mayor calidad final. También activa el Trellis por defecto (aunque se puede eliminar). Además permite aplicar algoritmos de desentrelazado; especialmente útil para cuando metemos un vídeo que tiene los campos invertidos (aunque en la próxima versión espero añadir una opción para invertir los campos).
Por último, he refactorizado el código para dejarlo un poco más limpio y facilitar el mantenimiento. Por supuesto aún falta mucho por hacer en ese aspecto, pero por algo hay que empezar…
Por cierto: acepto parches para el código 😉