Pourquoi Canonical choisit-il QT plutôt que GTK pour la prochaine génération de Unity?

Vous pouvez trouver la réponse sur la liste de diffusion et sur le blog de Mark Shuttleworth . Cet article répond probablement le mieux à cette question:

  

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.

GTK + ne prend pas en charge l’indépendance de résolution, les appareils mobiles modernes ont des densités de pixels très élevées. Si vous exécutez une application GTK + sur un écran mobile, tous les éléments de l’interface utilisateur seraient si petits qu’ils seraient inutilisables.

Cela a été un bogue ouvert sur GTK + depuis 2008 jusqu'à sa fermeture en 2014 avec "nous supporte maintenant la balance hi-dpi - ce n’est pas tout à fait la même chose, mais assez proche pour rendre ce bug obsolète »commente.

Lors de la sortie de GTK + 3, le projet avait l’opportunité parfaite d’ajouter une indépendance de résolution, car de toute façon, ils étaient en train de briser la compatibilité. Ils ont choisi de ne pas le faire et maintenant il est vraiment trop tard pour eux.

Sur la feuille de route GTK + , l’indépendance de la résolution est prévue pour la version 4.0, elle sortira donc la version 4.0 libérez après cela l'aura. S'ils s'en tiennent à ce plan, même les ordinateurs de bureau GNU / Linux devront abandonner GTK + car les moniteurs de bureau à haute résolution et les écrans d'ordinateur portables sont déjà disponibles et sont sur le point de devenir la nouvelle norme.     

Mon point de vue technique / pragmatique: Nokia a acheté Trolltech et a beaucoup investi dans QT. Son poids léger et ses années d'optimisation vers la plateforme mobile. Indépendamment de vos opinions actuelles sur Nokia, le N900 était en avance sur son temps… et il était basé sur Debian / QT… mais cher. Cependant, je n'ai aucune connaissance réelle des décisions.

Le ​​blog de Matt Zimmerman CTO sur Ubuntu CTO est également instructif:

  

C'est dans cet esprit que je pense à Qt récemment. nous   veulent rendre rapide, facile et sans douleur pour développer des applications pour   Ubuntu, et Qt est une option à explorer pour application   développeurs. En pensant à cela, j'ai réalisé qu'il y a tout à fait   un peu de communité entre les forces de Qt et certains des nouveaux   directions dans Ubuntu:

     

• Qt a une longue histoire d'utilisation sur ARM ainsi que sur x86 , en raison de sa popularité sur les périphériques embarqués. Les produits de consommation ont été construits   en utilisant Qt sur ARM depuis plus de 10 ans. Nous avons fabriqué des produits Ubuntu   disponible pour ARM depuis près de deux ans maintenant et 10.10 prend en charge plus   Des cartes ARM plus que jamais, y compris des tableaux de référence de Freescale,   Marvell et TI. Qt ajoute des optimisations ARMv7 pour bénéficier des dernières   Puces ARM. Nous faisons cela pour offrir aux OEM un choix de matériel,   sans sacrifier le choix du logiciel. Qt conserve ce même choix pour   développeurs d'applications.
  
• Qt est un framework d’application multiplate-forme , avec des ports officiels pour Windows, MacOS et autres, et des ports de communauté expérimentaux pour   Android, l'iPhone et WebOS. Un solide support multi-plateforme en était un   des principes originaux de Qt, et cela se voit dans la maturité de la   ports officiels. Avec Ubuntu Light installé sur les ordinateurs avec   Windows et Ubuntu One atterrissent sur Android et l’iPhone, nous avons besoin   interopérabilité avec d'autres plates-formes. Il y a aussi un grand   population de développeurs qui savent déjà cibler Windows, qui   peut également atteindre les utilisateurs Ubuntu en choisissant Qt.
  
• Qt dispose d’un système d’entrée tactile assez mature, qui prend désormais en charge le multi-touch et les gestes (y compris QML), même s’il est   complet sous Windows 7 et Mac OS X 10.6. Pendant ce temps, Canonical a été   travailler avec la communauté pour développer un multi-touch de bas niveau   framework pour Linux et X11, au profit de Qt et d’autres outils.   Ces efforts se rencontreront éventuellement au milieu.
  

Dans l’ensemble, je pense que Qt a beaucoup à offrir aux personnes qui souhaitent développer   applications pour (et sur) Ubuntu, particulièrement maintenant. Il a déjà des pouvoirs   les applications populaires multiplates-formes comme VLC, sans parler de la   toute la distribution de Kubuntu. Je l'ai manqué quand cela s'est passé l'année dernière,   mais Qt est maintenant disponible sous LGPL 2.1 ou GPL 3.0,   ce qui devrait le rendre adapté à pratiquement toutes les applications Ubuntu. Il   a un fort soutien commercial ainsi qu'une grande communauté de développeurs.   Bien entendu, aucune solution ne répondra à tous les besoins des développeurs.   Ubuntu prend en charge plusieurs toolkits et frameworks pour cette raison, mais   Qt semble être un excellent outil à avoir dans notre boîte à outils pour la route.

Une L'article d'Ars Technica traitant de cet article de blog fournit quelques informations:

  

Qt peut amener des développeurs tiers à Linux

     

Bien que Gtk + ait encore de la valeur et qu’il existe plusieurs raisons de   continuer à l'utiliser pour la construction de logiciels natifs Linux, Qt est maintenant le   choix évident pour les ISV qui ciblent plusieurs plates-formes. Qt   il est exceptionnellement facile de se conformer à l'aspect natif de   la plate-forme sous-jacente ou de construire une interface utilisateur totalement personnalisée qui   est parfaitement adapté à un appareil cible ou à un facteur de forme.

     

Nokia et Intel apportent MeeGo à un large éventail d’appareils,   attirer certains grands fournisseurs de logiciels commerciaux. Ce serait   relativement facile pour ces éditeurs de logiciels d'apporter leur Qt mobile   applications sur le bureau Linux en utilisant le même code qu'ils utilisent sur   MeeGo. Qt est spécifiquement conçu pour rendre cela facile. Ce serait un   énorme victoire pour les ordinateurs de bureau Linux   applications qui ne seraient pas disponibles autrement.

     

Il convient de noter que certains fournisseurs de logiciels mobiles de premier plan sont   déjà embrassé avec impatience Qt en raison de la prise en charge de Nokia pour la boîte à outils.   La société de streaming vidéo mobile Qik, par exemple, travaille sur un   port expérimental basé sur Qt de son application populaire dans le but de   l'apporter à MeeGo.

L'auteur de l'article est le créateur de l'application de messagerie instantanée Gwibber, il a donc une certaine expérience dans le développement d'interfaces graphiques pour Linux.