jueves, 4 de julio de 2013

QT avanza en su adopción en entornos libres: LXDE migra a QT


QT (la librería base de KDE y muchas apps libres/freeware), empieza su camino avanzando lentamente sobre el GTK+ (la librería base de Gnome).

El popular entorno de escritorio LXDE ya se portó QT y su primer batch de código ya puede ser compilado, dejando apreciar cómo va a ser LXDE-QT. Así que las siguientes versiones estables de LXDE van a estar basadas en algún momento, solamente en QT, dejando atrás la herencia de Gnome/GTK+.

LXDE-QT PREVIEW - http://blog.lxde.org/?p=1013



El desarrollo de LXDE, mirando un poco al futuro cercano

Leyendo un poco vemos que la gente de LXDE está honrando la inteligente decisión de no reinventar la rueda y están aprovechando el código y expertise de los developers de Razor-QT, un entorno gráfico liviano, bastante bueno que empezó su desarrollo hace poco (no llegando al nivel de LXDE o XFCE todavía), es de esperar que en algún momento, tal vez, las ideas se integren en un solo código (ya hay esa "onda" de no repetir el error de tener dos grandes grupos de developers haciendo casi lo mismo, tal como ocurrió con Gnome y KDE*).

De hecho la nueva versión 4.11 de KDE apunta a la posibilidad de tener varios shells intercambiables (al vuelo inclusive, con un solo click), totalmente funcionales, sobre el mismo conjunto de componentes base. Así, a futuro, si alguien quisiera implementar una copia fiel del estilo de interfaz gráfica de Gnome3, podría hacerlo sin problemas, aprovechando todo lo hecho para los demás shells (Plasma es el shell actual que se suele ver en los screenshots, y Plasma Active es otro shell para tabletas, también funcional y en versión estable).

Otros entornos como LXDE-QT y Razor-QT e inclusive una hipotética futura reescritura de XFCE, podrían llegar a usar la base de KDE, y convertirse en un shell.

Esta idea de muchos shells gráficos y una sola base de componentes surgió al ver los problemas propios de replicación de esfuerzos para desarrollar Plasma y Plasma Mobile, y también la problemática asociada GTK+3, en la que Gnome3 se integra tan fuertemente en GTK+3 que vuelve muy complicado escribir/generar otros shells gráficos sobre GTK3, tal como Cinnamon (de Linux Mint), MATE (cuyo desarrollo ya empezó a adoptar componente de Gnome3 y GTK3).


Los problemas de GTK+3
El desarrollo de GTK+3 luego de la versión 2 (sobre la que estaba construído Gnome 2), viene pasando por muchas instancias de problemas, el más importante es la falta de cuidado de los manteiners de GTK+3 cuando se desarrollan mejoras: muchas APIs cambian sin aviso, no hay documentación de los cambios, no hay retrocompatibilidad con lo que ya está codeado, etc.

El resultado es las aplicaciones GTK+3 tienen que ser parcialmente reescritas y/o corregidas (corrigiendo código que funciona bien y no tiene bugs), cada vez que ocurren cambios en GTK+3, más o menos impredeciblemente.

Esto está causando dolores de cabeza mayores a los developers que se pasaron a GTK+3 y por ello es que vemos pocas aplicaciones migrando a GTK+3 a pesar de que ya ha transcurrido bastante tiempo desde que está disponible.

El trasfondo de Gnome3 como entorno poco aceptado en Linux y ahora, ciudadano de 2da. en Red Hat Enterprise Linux (que no va a usar Gnome 3, sino la opción de Fallback), justamente su principal espónsor corporativo (la mayoría de los developers pagos de Gnome3 - los más activos, que llevan la voz cantante - son empleados de Red Hat), deja entrever circunstancias políticas complicadas en el presente de GTK+3, hay que "adaptarse" a mucho, para obtener lo mismo que en otras opciones está disponible sin esfuerzo.

GTK+2 era la opción de cero necesidad de adaptación, pero, ya fue descontinuado su soporte en favor de GTK+3, y con el rápido avance de las tecnologías gráficas en Linux (Wayland, el rápido desarrollo y mejora de drivers de Intel, ATI y Nvidia, etc.), quien permanezca "cerca" de GTK+2 mucho tiempo más corre el riesgo de que de una versión a otra de una distribución, sus aplicaciones ya no puedan siquiera arrancarse en Linux.

La opción de QT
Aquí es donde QT se presenta como la opción más indicada: todo lo que es negativo en GTK+3, se da a la inversa en QT.

  • Las versiones viejas son mantenidas en tiempos pre-definidos, inclusive adaptándolas a nuevas tecnologías, como las ya mencionadas. 
  • Las versiones nuevas soportan cierto nivel de retro-compatibilidad para compilar código de versiones viejas (piden menos cambios o ninguno). 
  • Las nuevas versiones de QT van implementando tecnología gráfica actualizada al año 2013, donde se puede llegar a construir aplicaciones usando lenguajes interpretados populares (Ruby, Python, etc.), QML a la cabeza de ellos con su QT Quick (que permite a los developers trabajar con QML para crear interfaces de usuario en vez de usar C++). El viejo C++ sigue plenamente disponible también.
  • La documentación de QT es extensiva, los entornos gráficos IDE para trabajar con QT (QT Creator, KDevelop, etc.) están a la altura de lo mejor disponible en el mercado.
  • El soporte multiplataforma de QT (Linux, Windows, Plataformas Mobile, etc.), y sus lenguajes soportados, permite que sea muy atractivo como expertise para los developers que colaboran en proyectos abiertos, ya van a poder portar esas skills ganadas en colaboración en proyectos opensource a proyectos laborales propios y a empleos pagos.
  • Etc.


Hay una especie de broma interna entre los desarrolladores de KDE (que está totalmente escrito sobre QT), y dice que lo único malo de KDE es que reescribió mal muchas cosas que QT ya hacía bien. Justamente desde la versión 4.10 en adelante, el foco del desarrollo de KDE es deshacerse de tanto código "solo KDE" como sea posible y en cambio utilizar solamente QT para programar aplicaciones.


Links

LXDE-Qt: Primer contacto



QT Creator



QML



Qt QML



Qt Quick Release Notes

Qt 5.0 - QtQuick C++ Module


Porting QML Applications to Qt 5



KDevelop


No hay comentarios: