Pocas veces me he llevado una decepción tan grande como este año con la asignatura de Interfaces Persona-Computador del Grado en Ingeniería Informática, y dejando de lado malos profesores o teoría más o menos obvia y aburrida, lo peor del conjunto ha sido QTJambi.

QTJambi

QTJambi, para los “desafortunados” que no hayáis tenido el “placer” de usarlo, es un port de QT para Java, de modo que podemos diseñar interfaces de forma muy similar a como haríamos con QT sólo que en Java (en el grado usamos Java como lenguaje principal, no C o C++ ). Sin embargo este port de QT es de lo peor que he visto hasta la fecha.

Abandonado

El proyecto QTJambi lleva abandonado una temporada, concretamente la última versión disponible (4.7.1-beta3) data de noviembre de 2010. Creo que ha pasado suficiente tiempo como para poder asumir que el proyecto está abandonado y que albergar cualquier esperanza de una actualización se acerca más a la imprudencia que a la duda razonable.

¿Multiplataforma?

Una de las virtudes de Java es que es multiplataforma, y tus aplicaciones creadas en Windows se podrán ejecutar en Mac, GNU/Linux o cualquier dispositivo que soporte Java. Pues bien, QTJambi rompe esta compatibilidad. Dejando de lado lo complicado que pueda llegar a resultar compilar una aplicación que use QTJambi para que incluya la versión de la librería para Mac o GNU/Linux, a la hora de ejecutarlo requiere de una máquina virtual de Java de 32 bits y algunas plataformas (en concreto OS X) ya no disponen de versión de Java de 32 bits.

Eclipse

Si pretendes trabajar con QTJambi de forma visual, sin tener que editar documentos XML, estás forzado a usar Eclipse y el plugin de QTJambi (por supuesto, en entornos de 32 bits). Eclipse es un buen IDE, pero a pesar de contar con un plugin para integrarlo con QTJambi las limitaciones se hacen evidentes en cuanto escribes un par de líneas de código.

Por ejemplo, el mecanismo de señales y slots requiere pasar los nombre de los métodos a ser llamados como Strings. Parece buena idea, pero haciendo esto pierdes todas las funciones de autocompletado y de refactorización. Así, además de no autocompletar el método de las clases, tampoco hay forma de refactorizar o detectar errores durante la compilación si has cometido algún error al escribir el nombre del método.

Documentación

La documentación sólo se puede calificar como “port a medias”. No es raro encontrarse con ejemplos escritos en C++ (aunque no es un gran problema ya que la traducción a Java es prácticamente inmediata), o métodos documentados como “This is a overloaded function provided for convenience.” (que resultan muy útiles cuando no sabes a qué método están sobrecargando, ni qué valores están usando para aquellos parámetros que sólo existen en el método sobrecargado).

En muchas ocasiones los parámetros están enigmaticamente documentados, al igual que los efectos secundarios de los métodos. Puedes verlos probando y viendo los resultados, pero ¡vamos! ¡La documentación se supone que está para evitar estas cosas!

Inestable y lento

Resulta frustrante trabajar con un compañero y que al usar una fuente que no tienes disponible en tu equipo, en lugar de ofrecerte reemplazarla por otra, cierre el IDE de golpe sin guardar ningún cambio y por supuesto sin aviso previo, teniendo acceso a una enorme traza que termina en un método de la clase QLabel. Resulta de lo más útil.

Esto por no hablar de lo realmente lento que vuelve a Eclipse. Los segundos necesarios para cambiar de un archivo a abierto a otro se cuentan con todos los dedos de ambas manos de varios miembros de tu equipo.

Integración con terceros

Si tu intención era hacer una subclase de algún componente para personalizarlo un poco (una lista con ciertos elementos por defecto, o una composición de varios Widgets para dar lugar a un único Widget más complejo) mejor es que aprendas algo de XML y te olvides de usar el editor visual.

Incluso las subclases directas son tratadas como “objetos desconocidos” y representadas con un rectángulo con un borde gris, obviamente sin acceso a ningún atributo, propiedad o información.

Personalización con CSS… interpretado por IE6

Casi todos los Widgets disponen del atributo stylesheet con el cual se puede usar CSS para personalizar el diseño, pero ¡alto! Ahí acaba la cosa. Si te preguntas por los selectores que se usan, descubrirás que tu mejor amigo en este tema es el ensayo y error… y paciencia, mucha paciencia.

Pronto te percatarás de que el soporte de CSS está muy limitado. Diría que el límite está entre IE5.5 e IE6. Si quieres poner un color de fondo, borde, relleno (padding) o margen, no tendrás muchos problemas (aunque yo me he encontrado con algunas dificultades en cuanto a borde se refiere). Si quieres hacer un borde curvo, usar degradados CSS o incluso usar pseudo clases CSS, vale más la pena que rediseñes tu interfaz para no necesitarlo.

Conclusión

QTJambi tiene algunas cosas muy interesantes, pero viniendo de Objective-C + UIKit/AppKit, casi todo lo que he encontrado han sido frustraciones. Después de pelear durante un par de horas para hacer el componente reusable que quieres y haber comprobado que funciona a la perfección, encontrarte con que es imposible añadirlo a la interfaz correctamente sin editar código XML con editores externos o añadir un Widget a modo de placeholder para luego reemplazarlo por el Widget real que crearás e inicializarás en tiempo de ejecución te da una sensación de “código sucio” contra la que has tratado de luchar con todas tus fuerzas.

Por no hablar de los cuelgues inesperados, la compatibilidad con otros sistemas operativos o el hecho de sentirte usando código que pasó a mejor vida mucho antes de que tú empezases a aprender Java.