¿Por qué Canonical elige QT sobre GTK para la próxima generación de Unity?

Se ha escrito tanto que estoy un poco confundido, pero si no me equivoco, Canonical está construyendo la próxima generación de Unity para dispositivos móviles con Qt, y en el futuro cercano el escritorio también se migrará a qt.

Solo quería saber las razones técnicas y / o políticas que impulsan esta decisión, y qué consecuencias podría significar para las aplicaciones de escritorio Ubuntu actualmente existentes.

Puede encontrar la respuesta en la lista de correo y en el blog de Mark Shuttleworth . Esta publicación de blog probablemente responde mejor:

Como parte de nuestra planificación para Natty + 1, necesitaremos encontrar algo de espacio en el CD para las bibliotecas Qt, y evaluaremos las aplicaciones desarrolladas con Qt para incluirlas en el CD y la instalación predeterminada de Ubuntu.

La facilidad de uso y la integración efectiva son valores clave en nuestra experiencia de usuario. Nos preocupamos de que las aplicaciones que elijamos sean armoniosas entre sí y con el sistema en su conjunto. Históricamente, eso ha significado que hemos dado una preferencia muy fuerte a las aplicaciones escritas usando Gtk, porque una cierta cantidad de armonía viene por defecto del uso del mismo kit de herramientas para desarrolladores. Dicho esto, con OpenOffice y Firefox desde el principio, Gtk claramente no es un requisito absoluto. Lo que estoy argumentando ahora es que son los valores los que son importantes, y el conjunto de herramientas es solo un medio para ese fin. Deberíamos evaluar las aplicaciones en función de cuán bien cumplan los requisitos, no perjudicarlas en función de las elecciones técnicas realizadas por el desarrollador.

Al evaluar una aplicación para la instalación predeterminada de Ubuntu, debemos preguntar:

• ¿Es software libre?
• ¿Es el mejor en su clase?
• ¿Se integra con la configuración y las preferencias del sistema?
• ¿Se integra con otras aplicaciones?
• ¿Es accesible para las personas que no pueden usar un mouse o teclado?
• ¿Se ve y se siente consistente con el resto del sistema?

Por supuesto, la elección del desarrollador de Qt no tiene influencia en los dos primeros. Qt ha estado disponible bajo la GPL durante mucho tiempo, y más recientemente estuvo disponible bajo la LGPL. Y hay un montón de software de primera clase escrito con Qt, es un juego de herramientas muy capaz.

Sin embargo, la configuración y las preferencias del sistema han sido durante mucho tiempo una causa de fricción entre Qt y Gtk. La integración con las configuraciones y preferencias del sistema es crítica para el sentido de que una aplicación "pertenece" al sistema. Afecta la capacidad de administrar esa aplicación usando las mismas herramientas que uno usa para administrar todas las demás aplicaciones, y el tipo de experiencia de configuración y preferencia que los usuarios pueden tener con la aplicación. Esto ha sido tradicionalmente un problema con las aplicaciones Qt / KDE en Ubuntu, porque todas las aplicaciones Gtk usan una tienda de preferencias manejable centralmente, y las aplicaciones KDE hacen las cosas de manera diferente.

Para abordar esto, Canonical está impulsando el desarrollo de enlaces dconf para Qt, de modo que es posible escribir una aplicación Qt que use el mismo marco de configuración que todo lo demás en Ubuntu. Hemos contratado a Ryan Lortie, quien obviamente conoce muy bien a dconf, y trabajará con algunas personas en Canonical que han estado usando Qt para trabajos de desarrollo personalizado para clientes. Estamos seguros de que el resultado será natural para los desarrolladores de Qt y una expresión completa de la semántica y el estilo de dconf.

El equipo de Qt ha trabajado durante mucho tiempo en la comunidad más amplia de Ubuntu: tenemos una excelente representación de Qt en UDS cada seis meses, el equipo de Kubuntu tiene una profunda experiencia e interés en el empaquetado y mantenimiento de Qt, hay mucho intercambio técnico entre Qt upstream y varios partes de la comunidad Ubuntu, incluido Canonical. Por ejemplo, la gente de Qt está trabajando para integrar uTouch.

Trazaría una distinción entre "Qt" y "KDE" en los lugares obvios. Una aplicación de KDE no sabe nada sobre la configuración del sistema dconf y, como resultado, no puede integrarse fácilmente con el escritorio de Ubuntu. ¡Así que no vamos a proponer Amarok para reemplazar a Banshee en el corto plazo! Pero creo que es totalmente plausible que dconf, una vez que tenga excelentes enlaces Qt, sea considerado por la comunidad de KDE. Hay mejores personas para dirigir esa conversación si lo desean, por lo que no voy a impulsar la idea aquí. Sin embargo, si una aplicación de KDE aprende a hablar dconf además de los mecanismos estándar de KDE, lo que debería ser sencillo, sería un candidato para la instalación predeterminada de Ubuntu.

La decisión de estar abierto a Qt no es en modo alguno una crítica de GNOME. Es una celebración de la diversidad y complejidad del software libre. Esos valores de facilidad de uso e integración siguen siendo valores compartidos con GNOME, y una excelente base para la colaboración con los desarrolladores de GNOME y los miembros del proyecto. Tal vez GNOME acepte Qt, tal vez no, pero si lo hace, nuestra voluntad de abrir este camino sería una contribución en el liderazgo. Es mucho más fácil crear un ecosistema vibrante si acepta una cierta divergencia de la forma canónica, por así decirlo. Nuestro trabajo de diseño se centra en GNOME, con configuraciones y preferencias como foco actual a medida que avanzamos hacia GNOME 3.0 y gtk3.

Por supuesto, esta es una oportunidad perfecta para aquellos que se burlarían de esa relación, pero desde mi punto de vista, lo que más importa es la sólida relación que tenemos con las personas que realmente escriben aplicaciones bajo el letrero de GNOME. Queremos ser la mejor manera de hacer que el trabajo duro de esos desarrolladores de software libre sea importante , con lo que queremos decir, la mejor manera de asegurar que marque una diferencia real en millones de vidas todos los días, y la mejor manera de conectarlos a sus usuarios

Para las buenas personas de Trolltech, ahora Nokia, que han hecho de Qt un gran juego de herramientas, gracias. Para desarrolladores que deseen usarlo y ser parte de la experiencia de Ubuntu, bienvenidos.

GTK + no admite independencia de resolución, los dispositivos móviles modernos tienen densidades de píxeles ultra altas. Si ejecuta una aplicación GTK + en una pantalla móvil, todos los elementos de la interfaz de usuario serían tan pequeños que serían inutilizables.

Este ha sido un error abierto en GTK + desde 2008 hasta que se cerró en 2014 con "ahora tenemos soporte de escala de alta resolución; no es exactamente lo mismo, pero lo suficientemente cerca como para dejar este error obsoleto".

Cuando se lanzó GTK + 3, el proyecto tuvo la oportunidad perfecta de agregar independencia de resolución, porque de todos modos estaban rompiendo la compatibilidad. Eligieron no hacerlo, y ahora es realmente demasiado tarde para ellos.

En el GTK + Roadmap , la independencia de resolución está prevista para la versión posterior a 4.0, por lo que lanzarán 4.0 y luego la versión principal después de eso la tendrá. Si se apegan a ese plan, incluso GNU / Linux de escritorio tendrá que abandonar GTK + porque los monitores de escritorio y portátiles de alto DPI ya están disponibles y están a punto de convertirse en la nueva normalidad.

Mi opinión sobre las razones técnicas / pragmáticas: Nokia compró Trolltech e invirtió mucho en QT. Es liviano y tiene años de optimización hacia la plataforma móvil. Independientemente de sus opiniones actuales sobre Nokia, el N900 estaba años adelantado a su tiempo ... y estaba basado en debian / QT ... pero caro. Sin embargo, no tengo un conocimiento real de las decisiones.

El blog del CTO de Ubuntu Matt Zimmerman también es informativo:

Es en este espíritu que he estado pensando en Qt recientemente. Queremos que sea rápido, fácil y sencillo desarrollar aplicaciones para Ubuntu, y Qt es una opción que vale la pena explorar para los desarrolladores de aplicaciones. Al pensar en esto, me di cuenta de que hay bastante en común entre las fortalezas de Qt y algunas de las nuevas direcciones en Ubuntu:

• Qt tiene una larga historia de uso en ARM y x86 , en virtud de ser popular en dispositivos integrados. Los productos de consumo se han creado utilizando Qt en ARM durante más de 10 años. Llevamos casi dos años haciendo que los productos de Ubuntu estén disponibles para ARM, y 10.10 admite más placas ARM que nunca, incluidas las placas de referencia de Freescale, Marvell y TI. Qt está agregando optimizaciones ARMv7 para beneficiar a los últimos chips ARM. Hacemos esto para ofrecer a los OEM una opción de hardware, sin sacrificar la elección del software. Qt conserva esta misma opción para los desarrolladores de aplicaciones.
• Qt es un marco de aplicaciones multiplataforma , con puertos oficiales para Windows, MacOS y más, y puertos comunitarios experimentales para Android, iPhone y WebOS. El fuerte soporte multiplataforma fue uno de los principios originales de Qt, y se nota en la madurez de los puertos oficiales. Con Ubuntu Light instalado en computadoras con Windows y Ubuntu One aterrizando en Android y iPhone, necesitamos interoperabilidad con otras plataformas. También hay una gran población de desarrolladores que ya saben cómo apuntar a Windows, que también pueden llegar a los usuarios de Ubuntu eligiendo Qt.
• Qt tiene un sistema de entrada táctil bastante maduro , que ahora es compatible con multitáctil y gestos (incluido QML), aunque solo está completo en Windows 7 y Mac OS X 10.6. Mientras tanto, Canonical ha estado trabajando con la comunidad para desarrollar un marco multitáctil de bajo nivel para Linux y X11, en beneficio de Qt y otros kits de herramientas. Estos esfuerzos eventualmente se encontrarán en el medio.

En general, creo que Qt tiene mucho que ofrecer a las personas que desean desarrollar aplicaciones para (y en) Ubuntu, particularmente ahora. Ya impulsa aplicaciones multiplataforma populares como VLC, sin mencionar toda la distribución de Kubuntu. Me perdí cuando esto sucedió el año pasado, pero Qt ahora está disponible bajo LGPL 2.1 o GPL 3.0, lo que debería hacerlo adecuado para prácticamente cualquier aplicación de Ubuntu. Tiene un fuerte respaldo comercial, así como una gran comunidad de desarrolladores. Por supuesto, ninguna solución única satisfará todas las necesidades de los desarrolladores, y Ubuntu admite múltiples kits de herramientas y marcos por este motivo, pero Qt parece una gran herramienta para tener en nuestra caja de herramientas para el camino por delante.

Un artículo de Ars Technica que discute esta publicación de blog proporciona algunas ideas:

Qt puede traer desarrolladores de terceros a Linux

Aunque Gtk + todavía tiene valor y hay varias razones para continuar usándolo para construir software nativo de Linux, Qt es ahora la opción obvia para los ISV que se dirigen a múltiples plataformas. Qt hace que sea excepcionalmente fácil ajustarse al aspecto nativo de la plataforma subyacente o crear una interfaz de usuario totalmente personalizada que se adapte de manera óptima a un dispositivo o factor de forma objetivo.

A medida que Nokia e Intel lleven MeeGo a una amplia gama de dispositivos, atraerá a algunos de los principales proveedores de software comercial. Sería relativamente fácil para esas compañías de software llevar sus aplicaciones Qt móviles al escritorio de Linux usando el mismo código que usan en MeeGo. Qt está específicamente diseñado para facilitarlo. Esta sería una gran victoria para el escritorio de Linux porque traería aplicaciones de terceros que de otro modo no estarían disponibles.

Vale la pena señalar que algunos proveedores importantes de software móvil ya están adoptando con entusiasmo Qt debido al soporte de Nokia para el kit de herramientas. La compañía de transmisión de video móvil Qik, por ejemplo, está trabajando en un puerto experimental basado en Qt de su popular aplicación con el objetivo de llevarlo a MeeGo.

El autor del artículo es el creador de la aplicación Gwibber IM, por lo que tiene cierta experiencia en el desarrollo de GUI para Linux.