Dans le cadre de notre planification pour Natty + 1, nous devrons trouver de l'espace sur le CD pour les bibliothèques Qt, et nous évaluerons les applications développées avec Qt pour les inclure dans le CD et installer Ubuntu par défaut.
La facilité d'utilisation et l'intégration efficace sont des valeurs clés de notre expérience utilisateur. Nous veillons à ce que les applications que nous choisissons soient harmonieuses entre elles et avec le système dans son ensemble. Historiquement, cela signifie que nous avons accordé une très forte préférence aux applications écrites avec Gtk, car une certaine harmonie vient par défaut de l'utilisation du même kit de développement. Cela dit, avec OpenOffice et Firefox depuis le début, Gtk n'est clairement pas une exigence absolue. Ce que je soutiens maintenant, c’est que ce sont les valeurs qui sont importantes, et la boîte à outils n’est qu’un moyen pour y parvenir. Nous devrions évaluer les applications en fonction de leur capacité à satisfaire aux exigences, sans les préjuger des choix techniques faits par le développeur.
En évaluant une application pour l'installation par défaut d'Ubuntu, nous devrions demander:
- est-ce un logiciel gratuit?
- est-ce le meilleur de sa catégorie?
- s'intègre-t-il aux paramètres et préférences du système?
- s'intègre-t-il avec d'autres applications?
- est-il accessible aux personnes qui ne peuvent pas utiliser une souris ou un clavier?
- Est-ce que ça a l'air cohérent avec le reste du système?
Bien sûr, le choix de Qt par le développeur n’a aucune influence sur les deux premiers. Qt lui-même est disponible sous la GPL depuis longtemps, et plus récemment est devenu disponible sous la LGPL. Et il y a beaucoup de meilleurs logiciels de classe écrits avec Qt, c'est une boîte à outils très performante.
Les paramètres du système et les préférences ont toutefois longtemps été une cause de friction entre Qt et Gtk. L'intégration avec les paramètres du système et les préférences est essentielle au sens d'une application "appartenant" au système. Cela affecte la capacité de gérer cette application en utilisant les mêmes outils que ceux utilisés pour gérer toutes les autres applications, ainsi que les types de paramètres et d’expérience que les utilisateurs peuvent avoir avec l’application. Cela a toujours été un problème avec les applications Qt / KDE sur Ubuntu, car les applications Gtk utilisent toutes un magasin de préférences gérable de manière centralisée, et les applications KDE font les choses différemment.
Pour résoudre ce problème, Canonical mène le développement de liaisons dconf pour Qt, de sorte qu’il est possible d’écrire une application Qt qui utilise le même cadre de paramètres que tout le reste dans Ubuntu. Nous avons passé un contrat avec Ryan Lortie, qui connaît très bien Dconf, et il travaillera avec des gens de Canonical qui utilisent Qt pour le développement personnalisé des clients. Nous sommes convaincus que le résultat sera naturel pour les développeurs de Qt, et une expression complète de la sémantique et du style de dconf.
L’équipe Qt a bien travaillé dans la communauté Ubuntu - nous avons une excellente représentation Qt à UDS tous les six mois, l’équipe de Kubuntu a une expérience et un intérêt profonds pour l’emballage et la maintenance Qt. en amont et diverses parties de la communauté Ubuntu, y compris Canonical. Par exemple, les gens de Qt travaillent pour intégrer uTouch.
Je ferais une distinction entre "Qt" et "KDE" dans les endroits évidents. Une application KDE ne sait rien de la configuration du système dconf et ne peut donc pas s'intégrer facilement avec le bureau Ubuntu. Nous ne proposerons donc pas à Amarok de remplacer Banshee de sitôt! Mais je pense qu'il est tout à fait plausible que dconf, une fois qu'il aura d'excellentes liaisons Qt, soit considéré par la communauté KDE. Il y a de meilleures personnes pour mener cette conversation s'ils le veulent, alors je ne vais pas pousser l'idée plus loin ici. Néanmoins, si une application KDE apprend à parler dconf en plus des mécanismes KDE standard, ce qui devrait être simple, ce serait un candidat pour l’installation par défaut d’Ubuntu.
La décision d’ouvrir Qt n’est en aucun cas une critique de GNOME. C'est une célébration de la diversité et de la complexité du logiciel libre. Ces valeurs de facilité d'utilisation et d'intégration restent des valeurs partagées avec GNOME et constituent une base idéale pour la collaboration avec les développeurs et les membres de projets GNOME. Peut-être que GNOME lui-même adoptera Qt, peut-être pas, mais si c'est le cas, notre volonté de faire avancer cette piste serait une contribution au leadership. Il est beaucoup plus facile de créer un écosystème dynamique si vous acceptez une certaine divergence par rapport à la méthode canonique, pour ainsi dire Notre travail sur le design est centré sur GNOME, avec les paramètres et les préférences comme objectif dans GNOME 3.0 et gtk3.
Bien sûr, c’est une opportunité parfaite pour ceux qui voudraient se moquer de cette relation, mais à mon avis, ce qui compte le plus, c’est la relation solide que nous avons avec les gens qui écrivent des applications sous la bannière GNOME. Nous voulons être le meilleur moyen de faire en sorte que le travail acharné de ces développeurs de logiciels libres soit important , par lequel nous entendons le meilleur moyen d’assurer une réelle différence dans des millions de vies chaque jour. la meilleure façon de les connecter à leurs utilisateurs.
Aux bons amis de Trolltech, maintenant Nokia, qui ont fait de Qt une excellente boîte à outils - merci. Aux développeurs qui souhaitent l'utiliser et faire partie de l'expérience Ubuntu - bienvenue.