Nuevo trasteo

Sí alguien todavía sigue este blog, recuerdo que nuevamente me cambié y ahora estoy en http://ceronman.com

Trasteo...

Me he cambiado de blog, ahora voy a escribir en http://wiki.freaks-unidos.net/weblogs/ceronman/. Estaré en ese blog probando que tal es la cosa. Si me gusta me quedo. Sino, vuelvo aquí.

P.D. Despues de muchos meses me he dado cuenta que la plantilla de este blog se ve horrible en Internet Explorer :(

Modificando Gaim

Uso Gaim para manejar todas mis conversaciones de mensajería instantánea. Me gusta tener todas las conversaciones en la misma ventana, no importa de qué red sea. Gaim me permite tener mis conversaciones de IRC, MSN, Yahoo y Google en la misma ventana. Sin embargo, hay algo que siempre me ha molestado de usar Gaim como cliente de IRC: No se puede ver en la lista de usuarios quién está ausente o away. Otros clientes como XChat o Chatzilla si hacen esto. Así que decidí aprovechar las ventajas del software libre y me propuse modificar Gaim para realizara esta tarea.

Aquí hay un pantallazo de XChat mostrando los usuarios away (en gris).

En un principio pensé que sería un cambio bastante fácil. Sin embargo, poco a poco me di cuenta de que había una razón por la cual un cambio tan aparentemente sencillo no se había hecho ya. El problema viene directamente desde el protocolo IRC. A diferencia de estados como de operador (op) o de voz (voice), el estado de ausencia (away) no puede obtenerse con un mensaje names. Para conocer si un usuario esta away hay que mandar un mensaje whois. La solución entonces para conocer qué usuarios están away es mandar un mensaje whois por cada usuario de un canal y, en base a su respuesta, colocar una etiqueta al usuario para indicar que esta away. La serie de mensajes whois tendría que mandarse cada cierto tiempo para mantener la lista actualizada. El problema de este enfoque es que se genera un gran overhead al tener que hacer los whois a cada rato. Por esta misma razón fué que a el mantenedor del módulo de IRC de Gaim, Ethan Blanton, no le sonó la idea de implementar esta característica. Cuando le dije que todos los clientes hacen eso, me dijo: if everybody else jumped off a bridge, would you? Creo que estaba de mal genio, cuando le pregunté en #gaim, estaba embolatado con el sistema de señales. Otro día tengo que insistir.

Definitivamente ver el código fuente de proyectos de software libre es una gran experiencia. Uno aprende muchas cosas. El código de Gaim me pareció muy bonito, organizado y fácil de entender. El código de XChat me pareció horrible. Husmear en el código de los programas también sirve para encontrar pequeños huevos de pascua muy curiosos, como lo que hace este pequeño fragmento del código del mensaje whois del módulo IRC de Gaim:

if (!strcmp(irc->whois.nick, "Paco-Paco")) {
    g_string_append_printf(info, 
     _("<br><b>Defining adjective:</b> Glorious<br>"));
}

Lo que hace este pedazo de código es que cada vez que se hace un whois al usuario Paco-Paco (Ethan Blanton), le colocaa al final del mensaje "Defining adjective: Glorious". Algo más curioso aún es que es una cadena traducible, por lo tanto, los traductores lo han traducido sin darse cuenta. Aquí hay un pantallazo de un whois a Paco-Paco:

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:



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:

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:

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...

Reportándose

Sí, aún sigo vivo. Estos días han estado muy complicados. Desde que comencé semestre no he podido organizar adecuadamente mi tiempo. Todo está hecho un ocho. Creo que el problema no es falta de tiempo, sino de organización. Espero aprovechar esta Semana Santa para descansar y organizar bien la cosa.

Con todo este tiempo sin escribir se me han ido acumulando los temas, así que aquí va un resumen rápido de lo que ha pasado (en orden cronológico) en este mes y pico:

Xgl

Si, instalé Xgl y Compiz en Dapper, gracias a la excelente guía que ha elaborado la comunidad de Ubuntu. Los resultados, tal y como lo esperaba, no fueron los mejores. El problema es mi tarjeta de video, una vieja ATI Radeon 7500. Desafortunadamente mi tarjeta no tiene soporte para Linux, por lo cual no cuento con los controladores propietarios de ATI. Me toca conformarme con los libres que, hay que admitirlo, son pésimos.

De todos modos la experiencia no fue tan mala, todos los efectos de Compiz se pueden apreciar. Sólo hay dos problemas: un molesto flickering y una enorme lentitud. Lo de la lentitud al parecer se debe a que los controladores están mandando a hacer por software muchas cosas que se deberían hacer por hardware. Es triste que mi tarjeta funcione tan bien en Windows y funcione peor que un chip integrado en Linux; quedándole grande incluso operaciones tan simples como las que hace Xgl (sin Compiz,).

Al final de cuentas mi Xgl no quedó usable, así que volví al servidor X.org normal. Lastimosamente no puede sacar pantallazos, por algunas razón salían negros. Sin embargo sigo pensando que el proyecto promete bastante, y es posible que para el próximo año se vean mejoras con los controladores libres.

La mayoría de los efectos de Compiz son para hacer el escritorio más "eye-candy", sin embargo, algunos realmente mejoran la usabilidad, como el efecto "expose", que ha sido "tomado prestado" del mundo de los Mac.

Modificando Skins de MediaWiki

Durante este mes decidí terminar el trabajo que había comenzado hace unos meses atrás de modificar la apariencia del sitio web del GLUC. Al principio la experiencia fue bastante tortuosa, especialmente porque modificar el skin monobook, que es del que todos parten, puede llegar a ser algo muy complicado. El problema con monobook es que hace un uso casi abusivo de las Hojas de Estilo en Cascada (CSS). Al final quedó un tema bastante interesante basado en FratMan de Jeason Pearce.

Aprendí varias cosas valiosas de mi experiencia modificando monobook, he aquí algunas para los interesados en aventurarse a hacer lo mismo:

1. No dedicarse exclusivamente a modificar los CSS. En ciertas ocasiones es necesario editar el archivo MonoBook.php, de otra forma habrá que hacer maromas con los CSS para lograr el comportamiento deseado. Pero ojo, las modificaciones a MonoBook.php sólo deberían ser de estructura, mover unos bloques de aquí para allá, por ejemplo, pero nunca de apariencia.
2. Se pueden tomar muchas ideas de lo que han hecho otros sitios modificando los skins de mediawiki. Verlo es muy fácil, simplemente hay que colocar un "skins/" al final de la URL del sitio y, en la mayoría de los casos, se tendrá acceso a los skins del sitio. Un ejemplo es: http://gluc.unicauca.edu.co/wiki/skins/ o http://www.mono-project.com/skins/
3. No hay que asustarse con los tweaks que hace Monobook para varios navegadores, en la mayoría de los casos se pueden ignorar.
4. Muchas imágenes que se aparentemente nunca se encuentran en el código HTML, son colocadas como background-image a través de CSS.
5. La extensión Web Developer de Firefox es demasiado útil, especialmente el modo de edición de CSS en tiempo real.

Otra tarea que tengo ahora que terminé la del GLUC es la de crear un skin para nUML, el nuevo proyecto del que hablo más abajo.

FLISOL

El 25 de Marzo se realizó el Festival Latinoamericano de Instalación de Software Libre. Es un evento que se realiza en forma simultanea en varias ciudades de Latinoamérica. Por supuesto nosotros en Popayán no podíamos faltar. Una vez más, Polux y GLUC unieron fuerzas en la realización de este evento. La asistencia estuvo bastante bien, aunque tuvimos muy pocas instalaciones. Creo que el día lluvioso desanimó a muchos a llevar su PC, y decidieron ir sólo a las charlas y ver las demostraciones. Esta vez también se notó menos presencia del GLUC, sus miembros se están dispersando por todo el mundo.

Fedora Core 5

Aprovechando el FLISOL decidí instalar el nuevo Fedora Core 5, remplazando mi Breezy. La verdad me ha sorprendido bastante. Creo que definitivamente Fedora es la distribución visualmente más atractiva y también más pulida. Hay muchas cosas nuevas que todavía no he explorado. Lo mejor de todo es que Fedora ahora viene con Mono y todos sus juguetes. Pero bueno, más adelante escribiré más detalladamente sobre esto. En especial, quiero esperar a que salga Ubuntu Dapper y poder hacer una comparación exhaustiva. Por ahora los dejo con este pantallazo del mismo momento en el que estoy escribiendo esto:

Pobre disco duro

También como consecuencia del FLISOL, se me daño mi disco duro y me tocó comprar uno nuevo. Afortunadamente tenía una copia de seguridad relativamente reciente, aunque de todos modos perdí algunas cosas interesantes como un script de Python que estaba haciendo para bajar e instalar automáticamente Mono y sus juguetes desde el SVN en forma paralela a la instalación actual, muy al estilo de jhbuild. En fin, me tocará volver a comenzarlo.

Magazín de Mono Hispano

Hace unas semanas surgió una idea bastante interesante en la lista de correo de Mono Hispano: crear un eZine. Al igual que muchos otros del grupo, la idea me pareció excelente. Inmediatamente me vinieron los recuerdos del Magazín que solíamos hacer en el GLUC.

Ya tango bosquejado el artículo que quiero escribir para el Magazín de Mono Hispano, se trata de una comparación de IronPython, Boo y C# 2.0 aunque por ahora el avance lo veo lento, espero poder sacar el tiempo para terminarlo.

nUML

Como lo comenta Rodolfo, el proyecto ExpertCoder se ha dividido en dos, por una parte esta la parte de generación de código y por la otra lo que tiene que ver con UML. Esta última parte se ha denominado nUML.

Por ahora mi inactividad es total en todos estos proyectos. No veo la hora de poder conseguir tiempo para continuar, especialmente con MonoCanvas.

Medellín

Bien, ya para terminar quiero decir que en menos de 7 horas me voy para Medellín, dónde están varios miembros de mi familia, a pasar la Semana Santa. Espero poder aprovechar estos días para descansar. La verdad es que me hace falta, el ritmo de los últimos días ha estado muy pesado. También, cómo dije antes, quiero organizar mi tiempo de aquí en adelante, ojalá pueda.

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:

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:

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:

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.

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.

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:

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.