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 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 et nous évaluerons les applications développées avec Qt pour les inclure sur le CD et l’installation par défaut d’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 harmonie découle 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 c’est les valeurs qui sont importantes et que la boîte à outils n’est qu’un moyen de parvenir à cette fin. 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 aux paramètres et 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 lui-même est disponible depuis longtemps sous la licence GPL et plus récemment sous la licence LGPL. Et il existe une multitude de logiciels de premier ordre écrits avec Qt, 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 employés 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 facilement s'intégrer 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 aura 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 d'être ouvert à 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 le meilleur moyen de faire en sorte que le dur labeur de ces développeurs de logiciels libres importe , ce qui signifie que nous voulons dire, le meilleur moyen de s’assurer qu’il fait une différence réelle dans des 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 seraient si petits qu'ils seraient inutilisables.
C’est n bogue ouvert sur GTK + depuis 2008 et ce, jusqu’à sa fermeture en 2014 avec "nous prenons désormais en charge la balance haute résolution - ce n’est pas tout à fait la même chose, mais elle est assez proche pour rendre ce bogue obsolète. "commentaire.
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 le GTK + Roadmap , 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.
Ubuntu CTO blog de Matt Zimmerman est aussi 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, je me suis rendu compte qu'il y avait pas mal de points communs entre les forces 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 de consommation utilisent Qt on ARM depuis plus de 10 ans. Nous proposons des produits Ubuntu disponibles pour ARM depuis près de deux ans maintenant, et 10.10 prennent en charge un plus grand nombre de cartes ARM, y compris les cartes de référence de Freescale, Marvell et TI. Qt ajoute des optimisations ARMv7 pour profiter des derniers 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, ainsi que 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 en cours d'installation sur des ordinateurs Windows et Ubuntu One atterrissant sur Android et sur l'iPhone, nous avons besoin de l'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 possède un système de saisie tactile assez développé , qui prend désormais en charge le multi-touch et les gestes (y compris QML), bien qu'il ne soit complet que sous Windows 7 et Windows. 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 multiplates-formes populaires telles que VLC, sans parler de la totalité de la distribution Kubuntu. 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 unique 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 discuter 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 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.