El Canvas más rápido del oeste

Esta semana Mario y yo hemos estado trabajado para optimizar al máximo MonoCanvas. La idea es lograr un rendimiento similar a Dia. Creo que hasta el momento se ha avanzado bastante. Yo he estado portando lo que ya estaba de GDI+ a Cairo directamente. Mario está haciendo una re-implementacion usando widgets de Gtk#. Lo interesante de este enfoque es que se aprovecha toda la lógica, ya bastante optimizada a través de los tiempos, que ya usa GTK+.

Para las pruebas con Cairo, he usado una pequeña aplicación Gtk# con 100, 200 o más widgets. He hecho pruebas con Dia y  empieaza a flaquear más o menos al mover 200 formas simultaneamente. Con este número de formas, la taza de actualización del canvas se reduce drásticamente, a menos de 4 repintadas por segundo. Los resultados con el nuevo canvas basado en Cairo son similares a los de Dia, sin embargo, hay que tener en cuenta que la versión de Cairo usa antialiasing y transparencias mientras que Dia no. La verdad es que estoy muy satisfecho y creo que incluso hay potencial para optimizar más.

Aquí hay unos pantallazos de MonoCanvas basado en Cairo y Dia:

Pantallazo de Mono Canvas Test Pantallazo de Dia

Por supuesto la versión de Cairo no es simplemente un cambio de GDI+ por Cairo, también son varios cambios que hacen más óptimo el programa. Dibujar a través de Gtk.DotNet es bastante lento. Y no sólo se trata de que el API System.Drawing esté basada en libgdiplus que a su vez esta implementada encima de Cairo, sino que el procedimiento de obtener un Drawing.Graphics de un Gdk.Drawable no es el más eficiente. He aquí un pedazo del código de Gtk.DotNet.Graphics:


public static System.Drawing.Graphics FromDrawable(Gdk.Drawable drawable, bool double_buffered)
{
...
Type graphics = typeof (System.Drawing.Graphics);
MethodInfo mi = graphics.GetMethod ("FromXDrawable", BindingFlags.Static | BindingFlags.NonPublic);
if (mi == null)
throw new NotImplementedException ("In this implementation I can not get a graphics from a drawable");
object [] args = new object [2] { (IntPtr) gdk_x11_drawable_get_xid (drawable.Handle), (IntPtr) display };
object r = mi.Invoke (null, args);
System.Drawing.Graphics g = (System.Drawing.Graphics) r;
...
return g;
}

Este método es el que se llama cada vez que se repinta  parte del canvas cuando se usa Gtk.DotNet. El cual se debe llamar, además de todas las operaciones de dibujo, unas 40 veces por segundo para lograr un movimiento fluido. Rápidamente se pueden observar dos problemas de rendimiento. Por un lado, el uso de System.Reflection para encontrar el método FromXDrawable y por el otro, la creación del objeto args.

Cuando se usa Cairo, en cambio, se usa el método Gdk.CairoHelper.Create que está basado en la implementación nativa que viene con el nuevo GTK+ 2.8, por lo tanto las cosas se hacen considerablemente más rápido.

La clave del rendimiento es dibujar lo menos posible. Definitivamente las operaciones de dibujo son las que más tardan, hay que hacer todo lo posible por no dibujar lo que no es necesario. Otras operaciones que puede pensarse son lentas, como las iteraciones a largas listas, en realidad no influyen mucho. Algo a tener en cuenta es que dibujar donde no se ve, es decir, fuera del QueueDrawArea también influye en el rendimiento, hay que evitarlo.

Otra cosa bastante curiosa es que el rendimiento depende bastante de la forma que se esté dibujando. Por ejemplo, una elipse es más lenta que un rectágunlo. Pero mucho más curioso es que una elipse con borde y sin relleno, es casi tres veces más lenta que una con relleno y sin borde. Algo similar pasa con los rectángulos.

El API de Cairo me ha gustado bastante. Es bastane parecido a OpenGL, por lo que es bastante familiar para mi. Aunque tiene alguas cosas raras, me ha gustado mucho más que System.Drawing, creo que es mucho más flexible.

Pronto uniremos el trabajo de Mario con el mio en la versión definitiva de MonoCanvas.

Edición de Vídeo Digital en Linux

Estoy adentrándome en la edición de vídeo digital con Linux y software de código abierto. Hasta ahora la experiencia no ha sido la mejor. A Linux le falta bastante para convertirse en una plataforma decente para edición de vídeo digital. Sin embargo, el futuro pinta bien, al menos se ve que hay trabajo en la dirección correcta.

Hasta ahora he hecho pocas pruebas de edición de vídeo con Linux. El punto de comparación será Windows, el cuál he vuelto a instalar en mi PC (sólo con propósitos comparativos :P). La verdad es que la experiencia de vídeo digital en Windows es bastante buena. No quiero ni imaginar qué tan buena sería en Mac OS X. En Linux toca por el lado difícil.

Bien, aquí está un compendio de las herramientas que he usado:

Dvgrab. En Windows, se prende la cámara, se conecta al puerto firewire, e inmediatamente sale un diálogo que dice: “Parece que ha conectado una cámara de video Samsung SCD 180, haga click aquí para capturar el video”. En un Linux out of the box simplemente no sucede nada cuando se conecta la cámara. Es necesario bajar una herramienta con interfaz de comandos, Dvgrab , para poder capturar el vídeo desde la cámara. Dvgrab es una herramienta bastante flexible y fácil de usar (para alguien acostumbrado a la línea de comandos, claro está), además, está bien adecuada para la automatización a través de scripts. Me gustaría bastante ver algo con HAL y DBus que permitiera mostrar un mensaje en la misma manera que lo hace Windows.

Kino, un editor de vídeo digital para Gnome. Es del mismo creador de Dvgrab. Mi experiencia con Kino no ha sido la mejor. La interfaz de captura de vídeo funciona cuando le da la gana y cuando captura curiosamente el vídeo no se ve, es bastante raro. La interfaz de Kino es bastante rara y confusa, a veces realizar simples tareas es un misterio. Aplicar ciertos filtros tarda toda una eternidad.

Pantallazo de Kino:

Kino Cut Tab

Diva. ¡Esta es la promesa de edición de vídeo digital en Linux! Diva es un proyecto para crear un editor de vídeo fácil de usar y escalable (a través de una arquitectura de plugins). Apenas está naciendo, pero es muy prometedor. Lo que lo hace prometedor es que han comenzado a hacer las cosas en la forma correcta. Diva está siendo desarrollada con Mono (obviamente :P) y esta siendo construida encima del asombroso GStreamer. Más interesante aún es el enfoque hacia la facilidad de uso que tiene Diva. Algunas personas como Miguel de Icaza han catalogado a Diva como la aplicación gráfica más pulida que hayan visto. Creo que estas apreciaciones se deben al fantástico widget de línea de tiempo que tiene, el cual ha sido creado en forma muy meticulosa usando Cairo y las nuevas características de GTK+ 2.8. Diva pinta muy bien, demasiado bien.

Pantallazos de Diva:

Diva Main Window Diva New Project

Diva Editing Window

Diva Export Dialog

Bueno, de todos modos mi experiencia con Diva no ha sido color de rosa, de hecho apenas hasta hace pocos días pude hacerla funcionar. Como dije antes, Diva es un proyecto que apenas está naciendo y, por supuesto, siempre está bleeding the edge. Una prueba de esto es que Diva necesita la versión CVS de GStreamer, y no sólo eso, necesita una versión parchada.

Después de bajar, parchar, compilar e instalar todo lo que necesitaba, mi experiencia al intentar usar Diva fue un horrible, muy horrible “Segmentation Fault“. Afortunadamente, como en todo proyecto de código abierto que ser respete, encontré un gran apoyo en la comunidad. Después de comentar el problema y cacharrear, la respuesta que obtengo de todo el mundo en #diva es “your problem IS very strange“. Luego de algunos días y gracias a la valiosa ayuda de Michael Dominic y al glorioso gdb, se pudo identificar el problema. Primero pensábamos que era Diva, de Diva pasamos a GStreamer, y de GStreamer pasamos al verdadero culpable: Libdv. Al final pude ingeniar una solución temporal. Sin embargo, la solución final estará dada cuando se arregle el bug que reporté a Fedora. Ya Jarod Wilson está trabajando en. ¡La comunidad del software libre es lo mejor!

Todo el cuento del bug en libdv me sirve para comentar un punto interesante. Varias veces atrás he escrito acerca de mi inconformidad con el método de instalar software usando los paquetes tradicionales de Linux. Bien, la experiencia con Diva me ha traído otro argumento más, que he denominado forks egoístas. Para entenderlo hay que analizar el caso de libdv. Libdv es una pieza de software algo vieja (teniendo en cuenta los estándares del código abierto), lleva dos años y medio sin actualizarse. Como era de esperarse, es difícil compilar libdv. Yo no pude hacerlo en mi Fedora Core 5. Tiene a gtk+ 1.x como dependencia (¡uich!). ¿Cómo hacen entonces los empaquetadores para compilarlo? Sencillo, le aplican a libdv una serie de parches que sirven para que se pueda compilar en sistemas modernos. Hasta ahí todo va bien. El problema radica en que estos parches son aplicados individual y aisladamente por cada distro o línea de distros. Los empaquetadores no se preocupan por integrar el parche al proyecto original, o apropiarse de él, si está abandonado, sino que lo aplican egoistamente al paquete de su distro. El resultado son pequeños forks de un proyecto.

En la vida real, la prueba de la existencia de los forks egoístas se puede apreciar en libdv. Para el paquete libdv, algunas distros usan unos parches y otras usan otros. Por ejemplo, en Fedora y Gentoo (pude comprobarlo gracias a que Travis Hansen, un gentooero, tenía el mismo problema) se aplican unos parches y en Debian y Ubuntu otros. Es por esta razón que en Fedora y Gentoo ocurría el bug con Diva y en Debian y Ubuntu no. No es que se trate de un insignificante parche, son bastantes cambios los que se hacen. Tampoco es que unos parches sólo sirvan para la configuración de determinada distro porque el problema lo solucioné usando los parches de Debian. Pienso que lo correcto es que estos parches vayan al repositorio oficial de libdv y todos puedan beneficiarse por igual.

De tanto hablar de paquetes y bugs me desvié del hilo principal de este post, la edición de vídeo digital. ¿Por qué estoy probando en este campo? La respuesta es que tengo pensado filmar y producir la cuarta versión de Semilla de Libertad, una serie de documentales sobre software libre en Colombia que ha realizado mi amigo Gustavo Gonzales. La idea es hacer el documental en la próximas Jornadas de Software Libre en Agosto. Quiero intentar editar la película con software libre. Ojalá se pueda.

Por cierto, también estoy probando la edición de vídeo con software propietario (para comparar vuelvo y repito :P). Ya bajé e instalé Adobe Premiere 7.0 Pro (La última versión, la 2.0, necesita un equipo más potente). Me parece que la interfaz es enredada y complicada, aún no aprendo a manejarlo. Windows Movie Maker, aunque modesto, me ha parecido muy fácil de usar, la interfaz no tiene pierde. Hay que seguir probando otras alternativas…

JDK 6 (Mustang) GTK+ Look and Feel

Durante estos días decidí probar la versión beta de Java 1.6, apodada “Mustang”. Según había leído por aquí y por allá, esta nueva versión traerá varias mejoras en cuestión de las interfaces gráficas Swing. La idea es que Swing tenga una apariencia más parecida a las interfaces nativas dependiendo del sistema operativo en el que se estén ejecutando. Me gusta mucho esta idea, y desde el principio soñé con ver algunas aplicaciones Swing que me gustan con la misma apariencia que el resto de mi entorno Gnome.

Se supone que Swing en JDK 6 hace uso de widgets nativos de GTK+, pero, según lo que probé, me parece que lo que en realidad pasa es que Swing trata de imitar el estilo de GTK+. Esto se puede comprobar fácilmente al ver diferencias sutiles (otras no tanto) entre Swing con tema GTK+ y una verdadera aplicación GTK+.

He aquí unos pantallazos de la aplicación de demostración que viene con el JDK, SwingSet2, con diferentes temas de Swing:

Pantallazo-SwingSet2-Swing-Metal

Pantallazo-SwingSet2-GTK-Clearlooks

Pantallazo-SwingSet2-GTK-Human

Desde aquí se ven varias cosas interesantes. Una es que el tema de GTK+ en Swing cambia en forma coherente con el tema actual de Gnome, prueba de ello es que dos de los pantallazos con tema GTK+ tienen tema de Gnome diferente, uno usa Clearlooks y el otro usa Human. Otra cosa bastante curiosa es ver cómo implementan una interfaz tipo MDI, que no están soportadas por GTK+. También se puede ver que a este estilo MDI le falta mucho por pulir, los botones de las ventanas internas aún están bastante burdos.

Para comparar como son renderizados algunos widgets específicos, aquí hay un diálogo típico de Gnome junto a algunos diálogos de preferencias de JEdit con tema GTK+ activado:

Pantallazo-Preferencias de ventana-GTK

Pantallazo-Opciones JEdit-Swing-GTK

Pantallazo-Opciones JEdit 2-Swing-GTK

La primera diferencia que se nota es que los widgets de Swing GTK+ usan una fuente de texto diferente de los widgets GTK+ reales. Para mi esto es crucial para no sentirse como en casa usando Swing. Ojalá que lo corrijan para la versión definitiva.

Algunos widgets en Swing GTK+ son casi idénticos a la versión real de GTK+, es el caso de los GtkCheckButton y los GtkRadioButton. Sin embargo, digo que son “casi idénticos” porque la versión de Swing no cuenta con pequeños detalles proporcionados por temas como Clearlooks, como los efectos de desvanecimiento suave en los GtkCheckButton. Otros widgets definitivamente son muy diferentes, es el caso de los GtkHScale y los GtkComboBoxEntry, que se notan bastante diferentes en la versión Swing. Otra cosa diferente son las barras de desplazamiento cuadradas al estilo GtkScrollBar en lugar de las redondeadas estilo GtkTextView.

Parece que la gente de Sun no sólo se ha preocupado por la similitud a nivel de widgets simples, sino que también han hecho algunos de los diálogos usuales bastante similares. He aquí algunos pantallazos:

Pantallazo-Abrir-GTK

Pantallazo-Abrir-JDK

Bueno, en realidad los diálogos de selección de archivos son muy diferentes. No encuentro el por qué Sun decidió usar el antiguo dialogo de abrir de GTK+ en lugar del nuevo. Este sí que me parece que es un punto negativo.

Pantallazo-Escoger Fuente-GTK

Pantallazo-Escoger Fuente-JDK

Aquí se pueden ver las diferencias entre los diálogos de selección de fuente. Se parecen bastante, aunque algunas cosas están en diferente orden y para ciertas cosas (texto de muestra) se usan widgets diferentes. De nuevo se nota aquí la diferencia entre las barras de desplazamiento diferentes, cuadradas en Swing GTK+ y redondeadas en Gnome.

Pantallazo-Escoger Color-GTK

Pantallazo-Escoger Color-JDK

Pantallazo-Escoger Color-Swing-Metal

Aquí hay una comparación de tres diálogos de selección de color. Uno es el original de Gnome, otro es de Swing GTK+ y otro es de Swing Metal. El diálogo de Swing GTK+ es bastante parecido al de Gnome. De nuevo se notan diferencias en los widgets, como por ejemplo los GtkSpinButtons. También hay cosas que faltan y cosas que se agregan, como el botón del gotero (se quitó) o la vista preliminar de texto (se agregó). En el triángulo de selección de color se puede notar como la versión de Swing GTK+ es mucho más burda, a diferencia de la versión Gnome que usa un bonito antialiasing, el cual viene desde GTK+ 2.8, gracias a Cairo. Supongo que Swing no usa nada similar a Cairo por debajo. Otra parte donde se nota una extraña inconsistencia es en los botones “aceptar” y “cancelar”, los cuales no usan los iconos de botones estándar. Y digo que es extraña esta inconsistencia es porque en el diálogo de selección de archivo si lo usaban.

En el último pantallazo se ve el mismo diálogo de selección de color, sacado exactamente de la misma parte de la misma aplicación, pero usando el tema Metal de Swing. Aquí se nota cómo un mismo diálogo de Swing puede verse radicalmente diferente dependiendo del tema que se use. No sé que tan bueno sea esto.

Al final dejo dos pantallazos comparando JEdit con tema GTK y tema Metal:

Pantallazo-jEdit-Swing-GTK

Pantallazo-jEdit-Swing-Metal

Aparte de las diferencias de apariencia, existe otro problema grave, gravísimo con Swing GTK+: El rendimiento. Y es que cuando se activa el tema de GTK+ la aplicación se vuelve considerablemente más lenta en comparación con el tema Metal, y, por supuesto, mucho más lenta que una aplicación GTK+ nativa. Esto si que es un gran problema para la adopción de este look and feel nativo.

Bueno, afortunadamente esta todavía es una versión beta. Estoy seguro que la gente de Sun va a corregir muchos de los errores que existen por el momento. El problema del rendimiento es realmente obligatorio de corregir, por lo menos hacer que sea igual de rápido que Swing Metal. De todos modos me parece que el enfoque que está tomando Sun de imitar GTK+ no es el más adecuado, creo que nunca va a ser posible tener un 100% de concordancia. Por ahora me parece que la mejor opción para tener un look and feel nativo en Java es SWT, usado por aplicaciones como Eclipse o Azureus.

Fedora, Aiglx y Xgl

Hace unos días escribía sobre los pros y los contras de Ubuntu y Fedora. Bien, creo que ahora tengo un nuevo punto a favor y también en contra de Fedora.

Una de las cosas que más me atrajo a Fedora desde el principio, fue que es una distro que siempre está probando cosas nuevas e interesantes, siempre está bleeding the edge. Una de las cosas que destaco del Proyecto Fedora es proyectos como Fedora Rendering Project o el Proyecto de Integración con Xen.

Fedora Rendering Project plantea una nueva opción bastante interesante a el impresionante Xgl de Novell; Se trata de Aiglx (Accelerated Indirect GL X). A diferencia de Xgl, Aiglx no trata de crear un nuevo servidor X, sino que plantea usar el servidor actual con ciertas extensiones y el uso de un Metacity especial con un composite manager (¿gestor de composición?) potencializado por Mesa. El resultado es un gestor de ventanas con la posibilidad de hacer los mismos efectos que hasta ahora se han mostrado en Xgl y Compiz.

Lo que hace el composite manager es básicamente aprovechar las ventajas de las nuevas tarjetas de vídeo para dibujar las ventanas en la parte no visible del framebuffer. Esto no sólo tiene la ventaja de ser muy rápido, sino que también permite hacer uso de efectos brindados por las capacidades de las tarjetas 3D como el alpha blending (que permite transparencias), entre otras.

Para mi lo que intenta hacer Aiglx es básicamente lo mismo que pretendía Luminocity; es más, creo que Aiglx no es más que un porte de Luminocity a Metacity. La idea es básicamente usar los beneficios del composite manager desde un servidor X normal. Esto tiene la gran ventaja de poder activar y desactivar los efectos 3D sin tener que cambiar de servidor X y de una forma tan simple como cambiar una clave del gconf. El problema de este enfoque es que no ese está usando a fondo todo el poder de la tarjeta 3D, sino que se esta utilizando solamente para la composición. Por otra parte, al seguir utilizando el servidor X normal, existen problemas con aplicaciones que usen, por ejemplo OpenGL o XVideo. Otra desventaja muy importante es que, al estar integrado el composite manager en Metacity, este sólo servirá para Gnome y dejará por fuera a otros escritorios como KDE.

Después de analizar las dos opciones: Aiglx y Xgl, definitivamente me parece que la mejor opción es Xgl. La razón es que el poder de las tarjetas 3D no sólo se debe usar para tener efectos visualmente llamativos, sino que la principal razón debe ser la velocidad. Dado que Xgl es un servidor X completamente nuevo, escrito por encima de OpenGL, se asegura que todas las operaciones de dibujo van a estar usando la aceleración 3D. Gracias a esto vamos a poder tener más cosas que simplemente lo que nos brinda Compiz, como por ejemplo renderizado de fuentes más rápido e incluso, quien sabe, hasta widgets 3D. Además, al ser Xgl un servidor X, sus ventajas van a poder ser aprovechadas por cualquier administrador de ventanas o entorno de escritorio.

Sin embargo, no todo es color de rosa para Xgl, yo le veo dos inconvenientes importantes: Una es la dificultad para pasar del modo acelerado al modo normal, lo cual podría ser causar problemas a personas que no tengan el hardware apropiado. El otro inconveniente tiene que ver con el backend que se está usando para Xgl actualmente: Xglx, que, a mi modo de ver, plantea un modo algo redundante aunque, eso si, bastante práctico. Xglx realiza las operaciones OpenGL sobre otro servidor X, es decir que a la larga tendríamos algo así: Xgl, un servidor X, corriendo sobre Xglx que a su vez corre sobre otro servidor X.

Para mi la solución ideal para el sistema gráfico en Linux, sería Xgl corriendo sobre Xegl, una alternativa a Xglx que permite que Xgl dibuje directamente sobre el framebuffer, evitándose de esta manera el segundo servidor X. Además que, al estar basado en el EGL de Khronos, sería mucho más portable. Sin embargo, Xegl todavía se ve bastante lejano. Existen muchos inconvenientes, uno es el problema de los drivers gráficos para que escriban directamente en el framebuffer, otro es la terquedad de tantos desarrolladores de X que pretenden seguir remachando el viejo X a probar nuevas y radicales ideas como Xegl. Esto es de lo que se prenden los de Aiglx para justificar su proyecto y es de lo que se queja Jon Smirl, ex desarrollador de Xegl, en su grandioso artículo sobre el estado del arte de los gráficos en Linux.

En fin, siempre he creído que la competencia en el software libre es buena y ayuda a que se logre un buena solución. Por eso me gusta que exista Gnome y también exista KDE, o que exista Fedora y también Ubuntu. Sin embargo en el caso de Aiglx vs Xgl la cosa es un poco distinta porque, como dijo alguien por ahí, no se trata de gustos, por lo que los dos no van a coexistir por mucho tiempo.

Herramientas para Python

Por estos días que he estado trabajando bastante en DeStar, estuve buscando algún buen IDE para programar en Python. Hasta ahora he estado programando con JEdit, un excelente editor de textos que poco tiene que envidiarle a Emacs o Vim y que es muy fácil de usar. La combinación de JEdit con gnome-terminal, Pdb y PyLint es bastante cómoda, sin embargo, quería probar algo un poco más integrado, así que me decidí a probar Pydev. PyDev es un plugin para el maravilloso Eclipse, el cual, por cierto, funciona perfectamente bajo GCJ, la implementación libre de Java.

PyDev tiene características bastante impresionantes:

  • Resaltado de sintaxis, explorador de clases y resaltado de errores. Bueno, esto es lo básico de todo IDE. Siendo Python un lenguaje dinámico, el resaltado de errores se hace utilizando PyLint. PyLint es bastante impresionante y configurable, puede detectar errores que van desde un objeto no declarado hasta prácticas feas de programación como líneas muy largas o nombres de variable muy cortos.
  • Code Completion, que no es más que el clásico asistente que ayuda sugiriendo qué se puede colocar digamos después de un punto. Muy útil a la hora de recordar nombres de métodos.
    Eclipse Screenshot with PyDev
  • Integración con Bicycle Repair Man, la herramienta para refactorizar código en Python. Esta si que es una gran característica que no había podido usar con JEdit. Por más que exista el HyperSearch y todo, este tipo de herramientas agilizan mucho las cosas.
    Eclipse Screenshot with PyDev
  • Depurador gráfico. Esta si que es una de las mejores características. Sé que Pdb es bastante fácil de usar, pero la verdad es que, a la hora de depurar, no hay nada como tener una buena perspectiva gráfica de todo lo que esta sucediendo. El depurador fue la principal razón que tuve para buscar un IDE y la verdad es que Eclispe con PyDev hacen un excelente trabajo en ese sentido.
    Eclipse Screenshot with PyDev
  • Integración con Subversion. Bueno, esto no es de PyDev, sino más bien de Subclipse, el plugin de Subversion para Eclispe. La integración es muy buena, cada cambio en la copia local con respecto al repositorio se muestra con algún icono, casi como tener un “svn st” en tiempo real. Por otra parte, todos los comandos usuales en SVN tienen su equivalente gráfico.
    Eclipse Screenshot with PyDev

Desafortunadamente no todo es perfecto. PyDev tiene algunos problemas que pueden llegar a ser molestos. Por una parte, PyDev no tiene soporte para PTL, el lenguaje de plantillas de Quixote, es decir que toca decirle a PyDev que maneje los archivos PTL como archivos normales de Python; aunque el depurador funciona bien para los PTLs, otras características como PyLint y el explorador de clases no lo hacen bien (En JEdit en cambio si funcionaba gracias al plugin Code Browser). Algo similar pasa con los archivos que tienen extensión diferente a “.py”, solo que en este caso simplemente no funciona nada, la única solución que he encontrado en este caso es renombrar los archivos temporalmente.

También he probado otras alternativas como JPyDebug, un plugin de Python para JEdit que agrega funciones de depuración, PyLint y explorador de clases, pero desafortunadamente este plugin sólo funcionaba cuando quería y decidí quitarlo. En fin, creo que probaré con PyDev por un tiempo y si no me gusta seguiré con el cómodo JEdit + Consola.

En resumidas cuentas: Eclipse + PyDev + Subclipse hacen un gran equipo

Detesto los paquetes – Parte 2

Definitivamente creo que la forma en que se están manejando los paquetes de software en las distribuciones de Linux es uno de los más grandes problemas que tiene la adopción del Software Libre en el escritorio. Y cuando hablo de las distribuciones de Linux hablo de todas, incluyendo Debian y Gentoo que se jactan de tener los mejores sistemas de paquetes.

Me molesta que cada distribución tenga un formato diferente de paquetes, e incluso las que comparten uno (como RPM), lo hacen incompatible. Esto lleva a que la labor de empaquetado se tenga que hacer una y mil veces. Un programa como Firefox tiene que ser empaquetado tantas veces como distribuciones hay. ¡Qué enorme gasto en trabajo de los colaboradores!, si las cosas funcionaran como deben, el desarrollador del programa debería empaquetar una vez y el paquete debería servir para cualquier distribución (en parte esto es lo que ocurre cuando se distribuye el código fuente, pero compilar definitivamente no es lo adecuado para un novato).

El hecho del empaquetado esté en manos de los que distribuyen y no de los que desarrollan el software es un problema mucho más grave de lo que parece. He aquí algunas razones:

  • No importa qué tan grande sea el ejercito de empaquetadores que se tenga, no es posible empaquetar todo el software. Por más que la gente de Debian diga que tiene n-mil paquetes, basta con mirar un poco gnomefiles.org para darse cuenta de que existen muchísimos programas sin empaquetar. El problema es aún peor con las distribuciones que no cuentan con la suerte de tener tantos colaboradores, simplemente tienen que resignarse con no tener el suficiente software, porque así es el sistema. Todo lo que no está empaquetado es difícil de instalar y no se integra bien con el resto de la distribución; esto hace que los usuarios muchas veces opten por simplemente no instalar lo que no está empaquetado, de hecho, tengo muchos amigos que no instalan nada que no se pueda apt-get installar, de ahí es donde surge la frase muy comúnmente escuchada que dice “Si no está en Debían, no exite”; la verdad es que se están perdiendo de un montón de programas.
  • Aún cuando se tenga un cierto programa empaquetado, no siempre se puede tener la última versión. Esto es bastante frustrante. ¿Por qué cuando sale el último Firefox no puedo probarlo porque no está empaquetado aún? El problema es peor aún con las versiones anteriores de la distribución. Por ejemplo, si yo uso Ubuntu Warty, nunca voy a disponer del paquete para Firefox 1.5, aún cuando si me bajo el binario de Mozilla.org si funciona. Es decir que los usuarios de Warty van a estar condenados a usar versiones viejas de todo el software y la única forma de conseguir un programa nuevo es actualizando toda la distribución. En otros casos es peor; en donde hay que pasarse a una versión inestable para poder probar el software nuevo. ¿Acaso suena lógico tener que actualizar a una versión inestable todo el sistema operativo, incluyendo Gnome, Gtk, etc sólo porque quiero probar el nuevo Firefox? Todo esto simplemente porque las personas de las distribuciones no quieren hacer los paquetes. Si el empaquetado estuviera en manos de los desarrolladores, la historia sería otra. Por ejemplo, la mayoría del software para Windows funciona desde la versión 95 hasta Vista ¿Que pasaría si para instalar un programa de Windows nos pidieran que obligatoriamente nos actualicemos a Vista? La actualización semestral de las distribuciones me parece una excelente idea, pero hay que aceptar que los usuarios normales no actualizan su sistema operativo cada 6 meses, eso es más bien para complacer a los geeks. Privar a los usuarios no expertos de ciertos programas no me parece una buena idea. Aunque hay casos en los que toca realizar la actualización, por cuestiones de dependencias, en muchos otros no, como el de Firefox.
  • Los sistemas de paquetes son completamente hostiles al software que no es libre y esto aleja a los ISVs. En mi opinión, no se puede tener una verdadera aceptación en el escritorio si los usuarios no tienen la libertad de escoger usar programas propietarios además de los libres. Además, ¿Qué pasa con los programas que no son del todo libres pero que su licencia tampoco es tan agreste como las típicas licencias propietarias? un ejemplo de este tipo de software es SciLab. Peor aún, no cualquiera puede ser empaquetador de una distribución, a veces hay que seguir rituales casi religiosos para poder hacerlo (véase cómo ser un DD). Los empaquetadores son los que deciden qué software se empaqueta. ¿Qué pasaría si para distribuir un programa de Windows hubiera que pedirle permiso a Microsoft? (Sé que la comparación es insensata, por favor no armar un flame por esto). En fin, me gusta la frase de la web de Zero Install: “You don’t need to be blessed by a distribution (or anyone else) to be part of Zero Install”.

Bueno, ya me desahogué un poco, la verdad es que a veces es bastante frustrante todo esto, lo peor es que a poca gente le interesa el problema, incluso he visto como la propuesta de crear un autopackage para Mono no sonó mucho. Por cierto, en el título dice “Parte 2” esto es porque hace poco más de un año había escrito sobre este mismo problema, y mencionaba algunas alternativas interesantes como Zero Install y Autopackage.

En resumidas cuentas: ¡Al diablo con el APT!

Revelando

Curso de Fotografía

Hace unas semanas me inscribí en un curso de fotografía que estaba dando el Foto Club de la Universidad. Desde hacía varios semestres quería inscribirme en el curso, pero no había tenido tiempo, este semestre tampoco tenía, así que me tocó decidirme e inscribirme como sea, ya que de otra forma nunca lo iba a hacer. En fin, el curso es a la antigua, con cámaras analógicas manuales, yo he estado usando la magnifica Canon A1 de mi papá. Al principio quería comprarme una cámara digital, pero la verdad es que me he dado cuenta que la fotografía analógica tiene su encanto, por eso tengo pensado conseguirme una Canon AE1 o similar, que sea manual.

En una de las prácticas del curso tomamos unas fotos en blanco y negro por varias zonas de Popayán. Hicimos todo el proceso manual, desde la escoger objetivo, filtros, velocidad y diafragma, hasta el mismo revelado y copiado. Este último, el revelado, es uno de los aspectos más interesantes de la fotografía analógica. Todo el proceso que va desde desenrollar el rollo completamente a oscuras en la etapa de revelado hasta ver cómo va apareciendo lentamente la foto en el papel bajo una tenue luz roja en la etapa de copiado, es simplemente fascinante.

Esta es mi hoja de contacto de aquella práctica:

Hoja de Contacto

Esta es una de las fotos ya copiada en papel:

Foto de un Árbol

Mono Canvas

Después de varios meses de no tocar el código de MonoCanvas ni de MonoUML, ayer decidí volver al retomar el trabajo. MonoCanvas ha cambiado mucho desde la última vez que lo vi, Mario ha avanzado bastante. Durante el fin de semana desempolvé el repositorio del SVN y empecé a corregir algunos bugs y a refactorizar un poco el código. Por ahora el trabajo que falta es re-escribir la parte de los elementos anidados, la cual era la causante de varios bugs, tengo pensando crear una nueva clase aparte para ello. De ahí seguirá el trabajo con las conexiones, que es importantísimo.

Una cosa que todavía me preocupa es el rendimiento, pese a que se han corregido varios bugs en Mono.Cairo por parte del equipo de Mono, me parece que todavía hay mucho por mejorar, tanto desde la parte de MonoCanvas como del mismo Mono, en fin, creo que luego hay que dedicarle un tiempo a eso más adelante.

Avance en MonoCanvas:

Screenshot de MonoCanvas

DeStar

Continuando con el tema del rendimiento, últimamente me estoy dedicando a mejorar el de DeStar. Después de analizar detenidamente, por fin he dado con el cuello de botella, que es una sincronización entre datos y metadatos que tienen los configlets. Esta sincronización se requiere cada vez que un configlet es accedido o modificado. El proceso de sincronización es lento porque tiene que recorrer todos los configlets, y por cada uno, recorrer todas sus variables y sincronizarlas, además de otras tareas de bricolaje. El proceso puede llegar a tardar hasta cuatro minutos con una configuración relativamente compleja, lo cual es exageradamente lento. La solución al problema es obvia, cambiar el sistema de sincronización y manejar los configlets con una estructura de datos más apropiada. Sin embargo, esta solución implica reescribir una enorme cantidad de código, es el problema de los errores a nivel de arquitectura. Lo que he estado analizando es cómo podría disminuir el problema sin reescribir mucho código, se me han ocurrido varias ideas, pero han tenido resultados desastrosos, en fin, hay que seguir probando…

Desocupandose un poco

Llevo bastantes días sin escribir nada. La verdad es que los últimos meses han estado bastante ocupado, por un lado estoy viendo varias materias en la universidad, de la cuales dos son especialmente consumidoras de tiempo: Telecomunicaciones 1 y Electrónica 1. Telecomunicaciones me quita tiempo porque el curso es básicamente el mismo que CCNA 1 y 2 que dan en la Academia Cisco, la cuestión es que en la AC cada curso se da en 80 horas, mientras que a nosotros nos están dando dos en escasas 60 horas, así que vamos muy rápido, prácticamente estamos teniendo dos exámenes de capítulo por semana. Lo bueno es que estamos viendo desde cómo hacer un cable UTP hasta cómo usar Ethereal. Electrónica, o sistemas digitales como se llama en otras partes, también absorbe el tiempo debido a que tengo que estar haciendo circuitos en protoboard, varios por semana, eso de estar pelando cables, y peleando con circuitos integrados defectuosos es bastante dispendioso, aunque divertido.

La otra razón por la cual he estado ocupado es que hace un par de meses empecé a trabajar medio tiempo. Estoy participando en el desarrollo de DeStar, una aplicación web para la administración de Asterisk. Estoy bastante contento con el trabajo, especialmente porque DeStar es software libre y porque está escrito en Python, y la verdad es muy agradable programar en ese lenguaje (o en Boo aún mejor, cuando se usa Mono). Por ahora, después del primer lanzamiento, mis contribuciones han sido bastante pequeñas, espero que poco a poco vayan aumentando.

Bien, ahora que ha pasado Octubre, que ha sido el mes más ocupado, creo que voy organizando las cosas y sacando tiempo para otros proyectos. Por un lado quiero retomar el trabajo en MonoCanvas, el cual no toco en meses, veo que Mario ha trabajado bastante en esta parte y eso me motiva a continuar con el trabajo. Por otro lado, la comunidad de Mono Colombia se ha reactivado, en gran parte gracias al encuentro que tuvimos algunos miembros en la pasada IV Semana Linux de la Universidad Distrital en Bogotá. Por ahora estamos pensando en comenzar un proyecto, espero que no nos dispersemos y podamos llegar a algo.

Camino a UMLCanvas 2.0

MonoUML

Estos días estoy trabajando bastante en sacar adelante, de una vez por todas, UMLCanvas# 2.0. El trabajo con System.Drawing (GDI+) es bastante agradable. En comparación con GnomeCanvas, System.Drawing es de más bajo nivel, pero tiene la ventaja de ser mucho más flexible. Luego de ver la noticia de que GTK 2.8 ahora requiere Cairo, estoy aún más convencido de que la elección ha sido la adecuada. Aunque lo que hay hasta ahora es bastante primitivo, creo que con todo lo que aprendimos haciendo la primera versión de UMLCanvas#, podemos avanzar lo suficientemente rápido.

El trabajo con Gtk# y System.Drawing es bastante interesante. Gracias a Gtk.DotNet es posible combinar dos librerías de Widgets: Gtk# y Windows.Forms. Más específicamente, Gtk.DotNet es un puente entre Gdk.Drawable y System.Drawing.Graphics, ahora como sabemos que Gtk se basa en Gdk y que Windows.Forms se basa en System.Drawing, podemos llevar esto a la interoperabilidad entre librerías que mencioné al principio.

El problema que tiene Gtk.DotNet es que está muy poco (por no decir nada) documentado. Prácticamente hay que aprender a base de ensayo y error. No lo digo por Gtk.DotNet en sí (que en realidad es sólo una clase y un método), sino en la interoperabilidad de las dos librerías como tal. Por ejemplo, uno de los problemas que tuve fue que no sabía como hacer para redibujar sólo una parte del canvas y no todo, cuando se usa sólo Windows.Forms, esto usualmente se hace invalidando el Control en dónde se está dibujando, para ello se hace uso del método Invalidate() de la clase Control. Sin embargo, cuando se combinan las dos librerías, se está dibujando sobre un objeto S.D.Graphics pero no existen ningún objeto Control; en su lugar se usa un Gtk.Widget (más específicamente un Gtk.DrawingArea). Lo que hay que hacer entonces es usar Gtk.Widget.QueueDrawArea() para invalidar un rectángulo. Como dije antes, no puede saber esto sino a base de un sistema de prueba y error.

Lamentablemente esto de la falta de documentación se está volviendo un común denominador en las librerías de Mono. Aunque duela decirlo, la única parte que está bien documentada es la parte que también hace MS (claro que una de las ventajas de Mono es poder aprovecharnos de todo eso). Prometo que una vez que haya avanzado un poco más con UMLCanvas# haré algo de documentación sobre Gtk.DotNet.

SLUD 4 y JSL

En octubre estaré viajando para Bogotá para asistir a dos eventos de Software Libre. Por un lado están las Primeras Jornadas de Software Libre, las cuales vienen a llenar el vacío que deja el Congreso Internacional de Software Libre que se hacía aquí en Colombia. Creo que esta versión de las JSL más bien debería ser la cero, porque todavía falta mucho para consolidar este evento. Por otro lado, esta la IV Semana Linux de la Universidad Distrital, la cual es organizada por nuestros amigos del Grupo Linux de la Universidad Distrital (GLUD). Este último evento parece que va a estar muy interesante, yo por mi parte envíe dos propuestas de ponencia: “Programación Multimedia con Mono” y “El lenguaje de programación Boo”, espero que acepten aunque sea una de ellas. En total en el GLUC enviamos 10 propuestas, así que va a haber bastante participación por parte de nuestro grupo.

Regresando de Vacaciones

Vacaciones

Acaban de terminar mis vacaciones de 15 días. Durante este tiempo me he dedicado a hacer nada, descansar, dormir hasta tarde, ver películas y pasarme algunos videojuegos. Incluso desde antes de entrar a vacaciones he estado bastante inactivo en todas las cosas referentes a software libre en las que estoy; ahora, después de terminadas las vacaciones, tengo baterías nuevas para continuar con todo.

Fedora

Hace unos días he instalado Fedora Core 4 y la verdad es que me ha gustado muchísimo. Ya desde hacía unos meses atrás había cambiado Ubuntu por FC3 y estaba bastante satisfecho, ahora con esta nueva versión estoy muy contento. FC4 es mucho más rápido de FC3 y viene con mucho software interesante. Quizá la aplicación que más me ha gustado es Evince, definitivamente GNOME necesitaba una aplicación como esta, es muy rápida y tiene aquellas características esenciales (copiar, buscar) que le faltaban a otros programas como Xpdf. Además ahora Nautilus previsualiza los archivos PDF, de esta forma mis libros electrónicos se ven realmente bien:

Nautilus Previsualizando PDFs

OpenOffice 2.0 me ha gustado muchísimo, aunque el nuevo look and feel parecido al de MS Word es un poco extraño al principio, especialmente con las teclas rápidas, creo que la mayoría de los cambios son para bien. Otra aplicación destacable es el Eclipse Nativo, totalmente basado en la implementación de Java de GNU.

Más aplicaciones

Definitivamente hacía falta la barra de Google para Mozilla Firefox, inmediatamente apareció la instalé. Por supuesto cambié la disposición de la barra de herramientas para que se ajuste a la barra, así me quedó:

Barra de Google para Firefox

Últimamente he notado que la temperatura de mi Athlon XP está demasiado alta, es por eso que me ha sido bastante útil este simple applet para el escritorio GNOME:

Applet de Temperatura para GNOME

Un programa muy llamativo que estoy probando es Drivel, un programa para escribir en el Blog. Lo vi por casualidad como programa de la semana en gnomefiles.org y me llamó mucho la atención, precisamente en este post estoy haciendo la prueba 🙂