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.