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 un futuro cercano el escritorio también migrará a qt.
Sólo quería saber las razones técnicas y/o políticas que impulsaron esta decisión, y qué consecuencias podría significar para las aplicaciones de escritorio Ubuntu actualmente existentes.
Respuesta1
Puede encontrar la respuesta en la lista de correo y enEl blog de Mark Shuttleworth. Esta publicación de blog probablemente responda 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 elegimos sean armoniosas entre sí y con el sistema en su conjunto. Históricamente, eso ha significado que hemos dado una fuerte preferencia a las aplicaciones escritas usando Gtk, porque una cierta cantidad de armonía viene por defecto del uso del mismo kit de herramientas de desarrollador. Dicho esto, dado que OpenOffice y Firefox estuvieron ahí desde el principio, Gtk claramente no es un requisito absoluto. Lo que estoy sosteniendo ahora es que son los valores los que son importantes, y el conjunto de herramientas es sólo un medio para ese fin. Deberíamos evaluar las aplicaciones en función de qué tan bien cumplen con los requisitos, no perjudicarlas en función de las decisiones técnicas realizadas por el desarrollador.
Al evaluar una aplicación para la instalación predeterminada de Ubuntu, deberíamos preguntarnos:
- ¿Es software libre?
- ¿Es el mejor de su clase?
- ¿Se integra con la configuración y preferencias del sistema?
- ¿Se integra con otras aplicaciones?
- ¿Es accesible para personas que no pueden usar un mouse o un teclado?
- ¿Se ve y se siente consistente con el resto del sistema?
Por supuesto, la elección de Qt por parte del desarrollador no influye en los dos primeros. El propio Qt ha estado disponible bajo la GPL durante mucho tiempo y, más recientemente, estuvo disponible bajo la LGPL. Y hay mucho software de primera clase escrito con Qt, es un conjunto de herramientas muy capaz.
Sin embargo, las configuraciones y preferencias del sistema han sido durante mucho tiempo una causa de fricción entre Qt y Gtk. La integración con la configuración y preferencias del sistema es fundamental para que una aplicación "pertenezca" al sistema. Afecta la capacidad de administrar esa aplicación utilizando las mismas herramientas que se usan para administrar todas las demás aplicaciones y el tipo de experiencia de configuración y preferencias 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 un almacén de preferencias administrable 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 sea 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 dconf, y trabajará con algunas personas de Canonical que han estado usando Qt para trabajos de desarrollo personalizados 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 bien durante mucho tiempo en la comunidad de Ubuntu en general: tenemos una excelente representación de Qt en UDS cada seis meses, el equipo de Kubuntu tiene una gran experiencia e interés en el empaquetado y mantenimiento de Qt, hay muchos buenos intercambios técnicos entre Qt upstream y varios partes de la comunidad Ubuntu, incluida Canonical. Por ejemplo, la gente de Qt está trabajando para integrar uTouch.
Harí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 completamente plausible que la comunidad KDE considere dconf, una vez que tenga excelentes enlaces Qt. Hay mejores personas para liderar esa conversación si así lo desean, así que no llevaré la idea más lejos aquí. Sin embargo, si una aplicación de KDE aprende a hablar dconf además de los mecanismos estándar de KDE, lo cual debería ser sencillo, sería candidata para la instalación predeterminada de Ubuntu.
La decisión de estar abierto a Qt no es de ninguna manera una crítica a 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. Quizás el propio GNOME adopte Qt, quizás no, pero si lo hace, entonces nuestra voluntad de abrir este camino sería una contribución al liderazgo. Es mucho más fácil crear un ecosistema vibrante si se acepta una cierta divergencia con respecto a la forma canónica, por así decirlo. Nuestro trabajo en diseño se centra en GNOME, siendo las configuraciones y preferencias el enfoque actual a medida que avanzamos hacia GNOME 3.0 y gtk3.
Por supuesto, esta es una oportunidad perfecta para que aquellos que quieran burlarse de esa relación lo hagan, pero en mi opinión lo que más importa es la sólida relación que tenemos con las personas que realmente escriben aplicaciones bajo el nombre de GNOME. Queremos ser la mejor manera de hacer que el arduo trabajo de los desarrolladores de software libreasunto, con lo que queremos decir, la mejor manera de garantizar que marque una diferencia real en millones de vidas cada día, y la mejor manera de conectarlos con sus usuarios.
A la buena gente de Trolltech, ahora Nokia, que ha hecho de Qt un gran conjunto de herramientas, gracias. Para los desarrolladores que deseen utilizarlo y ser parte de la experiencia Ubuntu, bienvenidos.
Respuesta2
GTK+ no admite la independencia de resolución. Los dispositivos móviles modernos tienen densidades de píxeles ultraaltas. Si ejecuta una aplicación GTK+ en la pantalla de un móvil, todos los elementos de la interfaz de usuario serían tan pequeños que resultarían inutilizables.
Esto ha sidoun error abierto en GTK+desde 2008 hasta que se cerró en 2014 con el comentario "ahora tenemos soporte de escala de alta resolución; no es exactamente lo mismo, pero lo suficientemente parecido como para dejar obsoleto este error".
Cuando se lanzó GTK+3, el proyecto tuvo la oportunidad perfecta para agregar independencia de resolución, porque de todos modos estaban rompiendo la compatibilidad. Decidieron no hacerlo y ahora ya es demasiado tarde para ellos.
Sobre elHoja de ruta GTK+, la independencia de resolución está planificada para la versión posterior a 4.0, por lo que lanzarán 4.0 y luego la versión principal posterior la tendrá. Si se apegan a ese plan, entonces incluso el escritorio GNU/Linux 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.
Respuesta3
CTO de UbuntuEl blog de Matt ZimmermanTambién es informativo:
Es con este espíritu que he estado pensando recientemente en Qt. Queremos que desarrollar aplicaciones para Ubuntu sea rápido, fácil y sencillo, 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 bastantes puntos en común entre las fortalezas de Qt y algunas de las nuevas direcciones en Ubuntu:
- Qt tiene una larga historia de uso enARM 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. Hemos estado ofreciendo productos Ubuntu para ARM durante casi dos años y 10.10 admite más placas ARM que nunca, incluidas 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 variedad de opciones de hardware, sin sacrificar la opción de software. Qt conserva esta misma opción para los desarrolladores de aplicaciones.
- qt es unmultiplataformamarco de aplicación, con puertos oficiales para Windows, MacOS y más, y puertos comunitarios experimentales para Android, iPhone y WebOS. Un 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 aspecto bastante maduro.entrada por tactosistema, que ahora tiene soporte para 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 quieran desarrollar aplicaciones para (y sobre) Ubuntu, especialmente ahora. Ya impulsa aplicaciones multiplataforma populares como VLC, sin mencionar toda la distribución de Kubuntu. Me lo 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 y una gran comunidad de desarrolladores. Por supuesto, ninguna solución única satisfará las necesidades de todos los desarrolladores, y Ubuntu admite múltiples kits de herramientas y marcos por esta razón, pero Qt parece una gran herramienta para tener en nuestra caja de herramientas para el camino por delante.
UnArtículo de Ars Technicadiscutir esta publicación de blog proporciona algunas ideas:
Qt puede traer desarrolladores externos a Linux
Aunque Gtk+ todavía tiene valor y hay varias razones para continuar usándolo para crear software nativo de Linux, Qt es ahora la opción obvia para los ISV que apuntan a múltiples plataformas. Qt hace que sea excepcionalmente fácil adaptarse a la apariencia nativa 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 de destino.
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 empresas de software llevar sus aplicaciones móviles Qt al escritorio Linux usando el mismo código que usan en MeeGo. Qt está diseñado específicamente para hacerlo fácil. Esto sería una gran victoria para Linux de escritorio porque traería aplicaciones de terceros que de otro modo no estarían disponibles.
Vale la pena señalar que algunos proveedores destacados de software móvil ya están adoptando con entusiasmo Qt debido al soporte de Nokia para el conjunto de herramientas. La empresa de transmisión de vídeo móvil Qik, por ejemplo, está trabajando en una versión experimental basada en Qt de su popular aplicación con el objetivo de llevarla 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.
Respuesta4
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 se adelantó años a su tiempo... y estaba basado en Debian/QT... pero era caro. Sin embargo, no tengo ningún conocimiento real de las decisiones.