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

Tant de choses ont été écrites que je suis un peu confus, mais si je ne me trompe pas, Canonical construit la nouvelle génération d'Unity pour appareils mobiles avec Qt et, dans un avenir proche, le poste de travail sera également migré vers qt.

Je voulais simplement connaître les raisons techniques et / ou politiques qui ont motivé cette décision et quelles en seraient les conséquences pour les applications de bureau Ubuntu existantes.

Vous pouvez trouver la réponse sur la liste de diffusion et sur le blog de Mark Shuttleworth . Ce billet de blog répond probablement mieux:

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.

GTK + ne prend pas en charge l’indépendance de résolution, les appareils mobiles modernes ont une densité de pixels extrêmement élevée. Si vous exécutez une application GTK + sur un écran de mobile, tous les éléments de l'interface utilisateur sont si petits qu'ils sont inutilisables.

C’est un bogue en cours sur GTK + depuis 2008 et jusqu’à sa fermeture en 2014 avec le commentaire «nous avons maintenant une prise en charge de l’échelle haute-dpi - ce n’est pas tout à fait la même chose, mais suffisamment près pour rendre ce bogue obsolète».

Lors de la sortie de GTK + 3, le projet offrait l’occasion idéale d’ajouter à l’indépendance de résolution, car de toute façon la compatibilité était rompue. 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 résolution est prévue pour la version ultérieure à 4.0, de sorte qu’ils publieront la version 4.0 puis la version principale suivante. S'ils s'en tiennent à ce plan, même les ordinateurs de bureau GNU / Linux devront abandonner GTK +, car des écrans de bureau et des écrans pour ordinateur portable à haute résolution 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 plate-forme mobile. Indépendamment de votre opinion actuelle sur Nokia, le N900 avait des années d'avance sur son époque ... 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, directeur technique d'Ubuntu , est également informatif:

C'est dans cet esprit que j'ai récemment pensé à Qt. Nous souhaitons rendre le développement d’applications pour Ubuntu rapide, simple et facile. Qt est une option à explorer pour les développeurs d’applications. En réfléchissant à cela, j'ai réalisé qu'il y avait pas mal de points communs entre les points forts de Qt et certaines des nouvelles orientations d'Ubuntu:

• Qt a une longue histoire d'utilisation sur ARM ainsi que x86 , en raison de sa popularité sur les appareils embarqués. Les produits grand public utilisent Qt on ARM depuis plus de 10 ans. Nous proposons des produits Ubuntu disponibles pour ARM depuis près de deux ans. 10.10 prend en charge plus de cartes ARM que jamais, y compris les cartes de référence de Freescale, Marvell et TI. Qt ajoute des optimisations ARMv7 pour profiter des dernières puces ARM. Nous le faisons pour offrir aux équipementiers un choix de matériel, sans sacrifier le choix de logiciel. Qt conserve le même choix pour les développeurs d'applications.
• Qt est un cadre d’application multiplate-forme , avec des ports officiels pour Windows, MacOS et autres, et des ports de communauté expérimentaux pour Android, iPhone et WebOS. Un support multi-plateforme fort était l’un des principes de base de Qt, comme en témoigne la maturité des ports officiels. Avec Ubuntu Light installée sur des ordinateurs Windows et Ubuntu One débarquant sur Android et l'iPhone, nous avons besoin d'une interopérabilité avec d'autres plates-formes. Il existe également un grand nombre de développeurs qui savent déjà comment cibler Windows et qui peuvent également atteindre les utilisateurs d’Ubuntu en choisissant Qt.
• Qt a un système de saisie tactile assez mature , qui prend désormais en charge le multi-touch et les gestes (y compris QML), bien que ce ne soit complet que sous Windows 7 et Mac OS X 10.6. Pendant ce temps, Canonical collabore avec la communauté pour développer un framework multi-touch de bas niveau pour Linux et X11, à l’avantage de Qt et d’autres toolkits. Ces efforts finiront par se rencontrer au milieu.

Globalement, je pense que Qt a beaucoup à offrir aux personnes souhaitant développer des applications pour (et sur) Ubuntu, en particulier maintenant. Il alimente déjà des applications multi-plateformes populaires telles que VLC, sans parler de la distribution Kubuntu dans son ensemble. Cela m’avait manqué lorsqu’il 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 compatible avec pratiquement toutes les applications Ubuntu. Il bénéficie d'un fort soutien commercial et d'une large communauté de développeurs. Bien entendu, aucune solution ne répond aux besoins de tous les développeurs. Ubuntu prend en charge plusieurs kits d’outils et infrastructures pour cette raison, mais Qt semble être un excellent outil à intégrer dans notre boîte à outils pour la route à venir.

Un article d'Ars Technica traitant de ce blog fournit quelques informations:

Qt peut amener des développeurs tiers à Linux

Bien que Gtk + ait toujours une valeur et qu'il existe de nombreuses raisons de continuer à l'utiliser pour construire un logiciel Linux natif, Qt est désormais le choix évident pour les éditeurs de logiciels qui ciblent plusieurs plates-formes. Qt facilite exceptionnellement la conformité à l'apparence native de la plate-forme sous-jacente ou la création d'une interface utilisateur totalement personnalisée et parfaitement adaptée à un périphérique cible ou à un facteur de forme.

Nokia et Intel proposeront MeeGo à un large éventail d'appareils, ce qui attirera de grands vendeurs de logiciels commerciaux. Il serait relativement facile pour ces éditeurs de logiciels d’apporter leurs applications Qt mobiles sur le bureau Linux à l’aide du même code que celui qu’elles utilisent sur MeeGo. Qt est spécialement conçu pour rendre cela facile. Ce serait un gain énorme pour Linux de bureau car cela apporterait des applications tierces qui ne seraient autrement pas disponibles.

Il convient de noter que certains éditeurs de logiciels mobiles de premier plan ont déjà adopté Qt avec enthousiasme en raison de la prise en charge par Nokia de ce kit d'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 possède donc une certaine expérience dans le développement d'interfaces graphiques pour Linux.