Dans le cadre de notre planification pour Natty + 1, nous devrons trouver de l'espace sur le CD pour les bibliothèques Qt. Nous évaluerons ensuite les applications développées avec Qt à inclure sur le CD et à installer par défaut Ubuntu.
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 choisies soient en harmonie les unes avec les autres et avec le système dans son ensemble. Historiquement, cela signifiait que nous accordions une très grande préférence aux applications écrites avec Gtk, car une certaine quantité d’harmonie provient par défaut de l’utilisation du même toolkit pour développeurs. Cela dit, avec OpenOffice et Firefox présents depuis le début, Gtk n’est clairement pas une exigence absolue. Ce que je dis maintenant, c'est que ce sont les valeurs qui importent et que la trousse à outils n'est qu'un moyen d'atteindre cet objectif. Nous devrions évaluer les applications sur la base de leur degré de satisfaction aux exigences, et non les préjuger des choix techniques effectués par le développeur.
Lors de l'évaluation d'une application pour l'installation par défaut d'Ubuntu, nous devrions demander:
- est-ce un logiciel libre?
- est-ce le meilleur en classe?
- s'intègre-t-il avec les paramètres et les préférences du système?
- s'intègre-t-il avec d'autres applications?
- Est-il accessible aux personnes ne pouvant utiliser une souris ou un clavier?
- Cela ressemble-t-il au reste du système?
Bien entendu, le choix de Qt par le développeur n’a aucune influence sur les deux premiers. Qt est lui-même disponible sous licence GPL depuis longtemps, et plus récemment sous LGPL. Et il y a beaucoup de logiciels de pointe écrits avec Qt, c'est une boîte à outils très performante.
Les paramètres système et les préférences ont cependant longtemps été une cause de friction entre Qt et Gtk. L'intégration avec les paramètres et les préférences du système est essentielle au sens d'une application «appartenant» au système. Cela affecte la capacité de gestion de cette application à l'aide des mêmes outils que ceux utilisés pour gérer toutes les autres applications, ainsi que du type d'expérience de paramètres et de préférences que les utilisateurs peuvent obtenir 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 remédier à cela, Canonical pilote le développement des liaisons dconf pour Qt, de sorte qu'il est possible d'écrire une application Qt utilisant le même cadre de paramètres que tout le reste dans Ubuntu. Nous avons passé un contrat avec Ryan Lortie, qui, de toute évidence, connaît très bien dconf. Il travaillera avec des collaborateurs de Canonical qui utilisent Qt pour des travaux de développement personnalisés pour leurs clients. Nous sommes confiants que le résultat sera naturel pour les développeurs Qt et constituera une expression complète de la sémantique et du style de dconf.
L’équipe Qt a longtemps bien travaillé dans la communauté Ubuntu - nous avons une excellente représentation de Qt à UDS tous les six mois, l’équipe de Kubuntu possède une expérience et un intérêt profonds pour l’emballage et la maintenance de Qt, il y a beaucoup de bons échanges techniques entre Qt en amont et divers 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 connaît rien de la configuration du système dconf et ne peut donc pas s'intégrer facilement au bureau Ubuntu. Nous ne proposerons donc pas Amarok pour remplacer Banshee de si tôt! Mais je pense qu’il est tout à fait plausible que dconf, une fois qu’il a de très bonnes liaisons Qt, soit pris en compte par la communauté KDE. Il y a de meilleures personnes pour mener cette conversation si elles le souhaitent, je ne vais donc pas pousser l'idée plus loin ici. Néanmoins, si une application KDE devait apprendre à parler de dconf en plus des mécanismes standard de KDE, ce qui devrait être simple, elle serait candidate à l'installation par défaut d'Ubuntu.
La décision de s’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 excellente base pour la collaboration avec les développeurs et les membres du projet GNOME. Peut-être que GNOME lui-même adoptera Qt, peut-être pas, mais s'il le fait, notre volonté de nous engager dans cette voie contribuerait grandement 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 de conception est centré sur GNOME, les paramètres et les préférences étant au centre des préoccupations lorsque nous passons à GNOME 3.0 et à gtk3.
Bien sûr, c’est une occasion parfaite pour ceux qui se moqueraient de cette relation, mais à mon avis, ce qui compte le plus, c’est la relation solide que nous entretenons avec des personnes qui écrivent des applications sous la bannière GNOME. Nous voulons être la meilleure façon de faire le travail de ces développeurs de logiciels libres matière , nous entendons par là, la meilleure façon de garantir cela fait une différence réelle en millions de vies chaque jour, et la meilleure façon de les connecter à leurs utilisateurs.
Aux bonnes gens de Trolltech, maintenant Nokia, qui ont fait de Qt un formidable outil - merci. Aux développeurs qui souhaitent l'utiliser et faire partie de l'expérience Ubuntu - bienvenue.