Tant de choses ont été écrites que je suis un peu confus, mais si je ne me trompe pas, Canonical construit la prochaine génération d'Unity pour les appareils mobiles avec Qt, et dans un avenir proche, le bureau sera également migré vers qt.
Je voulais simplement connaître les raisons techniques et/ou politiques qui motivent cette décision, et les conséquences qu'elle pourrait avoir pour les applications de bureau Ubuntu actuellement existantes.
Vous pouvez trouver la réponse sur la liste de diffusion et sur Le blog de Mark Shuttleworth . Cet article de blog y répond probablement le 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 tenons à 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 donné une très forte préférence aux applications écrites à l'aide de Gtk, car une certaine harmonie découle par défaut de l'utilisation de la même boîte à outils de développement. Cela dit, avec OpenOffice et Firefox qui sont là 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 que la boîte à outils n'est qu'un moyen d'y parvenir. Nous devrions évaluer les applications en fonction de la façon dont elles répondent aux exigences, et non pas les préjuger sur la base des choix techniques faits par le développeur.
Lors de l'évaluation d'une application pour l'installation par défaut d'Ubuntu, nous devons nous demander :
- s'agit-il d'un logiciel libre ?
- est-il 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 à d'autres applications ?
- est-il accessible aux personnes qui ne peuvent pas utiliser une souris ou un clavier ?
- L'aspect et la sensation sont-ils cohérents avec le reste du système ?
Bien entendu, le choix de Qt par le développeur n'a aucune influence sur les deux premiers points. Qt lui-même est disponible sous licence GPL depuis longtemps, et plus récemment sous licence LGPL. Et il y a beaucoup de logiciels de premier ordre écrits avec Qt, c'est une boîte à outils très performante.
Les paramètres du système et les préférences, cependant, ont longtemps été une cause de friction entre Qt et Gtk. L'intégration des paramètres et des préférences du système est essentielle pour qu'une application ait le sentiment d'appartenir au système. Elle affecte la capacité de gérer cette application à l'aide des mêmes outils que ceux utilisés pour gérer toutes les autres applications, et le type d'expérience que les utilisateurs peuvent avoir avec l'application en matière de paramètres et de préférences. Cela a traditionnellement été un problème avec les applications Qt / KDE sur Ubuntu, parce que 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 à ce problème, Canonical est à la tête du développement des liaisons dconf pour Qt, afin qu'il soit possible d'écrire une application Qt qui utilise le même cadre de paramètres que tout le reste d'Ubuntu. Nous avons passé un contrat avec Ryan Lortie, qui connaît évidemment très bien dconf, et il travaillera avec certaines personnes de Canonical qui ont utilisé Qt pour des travaux de développement personnalisés pour des clients. Nous sommes convaincus que le résultat sera naturel pour les développeurs Qt et qu'il exprimera parfaitement la sémantique et le style de dconf.
L'équipe Qt travaille depuis longtemps en bonne intelligence avec la communauté Ubuntu au sens large - nous avons une excellente représentation de Qt à l'UDS tous les six mois, l'équipe Kubuntu a une grande expérience et un grand intérêt pour le packaging et la maintenance de Qt, il y a beaucoup de bons échanges techniques entre Qt en amont et diverses parties de la communauté Ubuntu, y compris Canonical. Par exemple, les gens de Qt travaillent à l'intégration de uTouch.
Je ferais une distinction entre "Qt" et "KDE" aux endroits évidents. Une application KDE ne sait rien de la configuration du système dconf et ne peut donc pas s'intégrer facilement au bureau Ubuntu. Nous n'allons donc pas proposer Amarok pour remplacer Banshee de sitôt ! Mais je pense qu'il est tout à fait plausible que dconf, une fois qu'il aura de bons liens avec Qt, soit considéré par la communauté KDE. Il y a de meilleures personnes pour mener cette conversation si elles le souhaitent, donc je ne pousserai pas l'idée plus loin ici . Néanmoins, si une application KDE apprenait à parler de dconf en plus des mécanismes standards de KDE, ce qui devrait être simple, elle serait un candidat pour 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 une excellente base pour la collaboration avec les développeurs de GNOME et les membres du projet. Peut-être que GNOME lui-même adoptera Qt, peut-être pas, mais si c'est le cas, notre volonté d'ouvrir cette voie sera une contribution au leadership. Il est beaucoup plus facile de créer un écosystème dynamique si l'on accepte une certaine divergence par rapport à la voie canonique, pour ainsi dire Notre travail sur la conception est centré sur GNOME, avec les paramètres et les préférences comme point de mire actuel alors que nous passons à GNOME 3.0 et gtk3.
Bien sûr, c'est l'occasion idéale pour ceux qui veulent se moquer de cette relation de le faire, mais à mon avis, ce qui compte le plus, c'est la relation solide que nous avons avec les personnes qui écrivent réellement des applications sous la bannière GNOME. Nous voulons être le meilleur moyen de rendre le dur labeur de ces développeurs de logiciels libres matière Nous entendons par là la meilleure façon de faire en sorte qu'il fasse une réelle différence 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 une formidable 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 la 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 seront si petits qu'ils seront inutilisables.
Cela a été un bug ouvert sur GTK+ depuis 2008 jusqu'à ce qu'il soit fermé en 2014 avec un commentaire du type "nous avons maintenant un support pour les échelles hi-dpi - ce n'est pas tout à fait la même chose, mais suffisamment proche pour rendre ce bug obsolète".
Lorsque GTK+3 a été publié, le projet a eu l'occasion parfaite d'ajouter l'indépendance de la résolution, parce qu'ils brisaient la compatibilité de toute façon. Ils ont choisi de ne pas le faire, et maintenant il est vraiment trop tard pour eux.
Sur le Feuille de route GTK L'indépendance de la résolution est prévue pour la version postérieure à la 4.0. Ils sortiront donc la 4.0 et la version majeure qui suivra l'intégrera. S'ils s'en tiennent à ce plan, même les GNU/Linux de bureau devront abandonner GTK+, car les écrans de bureau et les écrans d'ordinateurs portables à haute résolution sont déjà disponibles et sont sur le point de devenir la nouvelle norme.
Mon point de vue sur les raisons techniques/pragmatiques : Nokia a acheté Trolltech et a beaucoup investi dans QT. Il est léger et a été optimisé pendant des années pour les plateformes mobiles. Indépendamment de vos opinions actuelles sur Nokia, le N900 avait des années d'avance sur son temps... et il était basé sur Debian et QT... mais il était cher. Cependant, je n'ai aucune connaissance réelle des décisions.
Directeur technique d'Ubuntu Le blog de Matt Zimmerman est également instructif :
C'est dans cet esprit que je me suis penché sur Qt récemment. Nous voulons qu'il soit rapide, facile et sans douleur de développer des applications pour Ubuntu, et Qt est une option qui mérite d'être explorée par les développeurs d'applications d'applications. En y réfléchissant, je me suis rendu compte qu'il y a pas mal de points communs entre les points forts de Qt et les points faibles de Qt. les points forts de Qt et certaines des nouvelles orientations d'Ubuntu. nouvelles orientations d'Ubuntu :
- Qt a une longue histoire d'utilisation sur ARM et x86 en raison de sa popularité sur les appareils embarqués. Des produits grand public ont été construits en utilisant Qt sur ARM depuis plus de 10 ans. Nous avons fait des produits Ubuntu pour ARM depuis près de deux ans maintenant, et la version 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 afin de bénéficier des dernières puces ARM. Nous faisons cela afin d'offrir aux OEM un choix de matériel, sans sacrifier le choix du logiciel. Qt préserve ce même choix pour les développeurs d'applications.
- Qt est un multiplateforme avec des ports officiels pour Windows, MacOS et d'autres, et des ports expérimentaux de la communauté pour Android, l'iPhone et WebOS. Un fort support multiplateforme était l'un des principes principes initiaux de Qt, et cela se voit dans la maturité des ports officiels. ports officiels. Avec Ubuntu Light qui est installé sur des ordinateurs avec Windows, et Ubuntu One qui atterrit sur Android et l'iPhone, nous avons besoin d'une l'interopérabilité avec les autres plateformes. Il y a aussi une grande population de développeurs qui savent déjà comment cibler Windows, qui peuvent également atteindre les utilisateurs d'Ubuntu en choisissant Qt.
- Qt dispose d'une entrée tactile qui prend désormais en charge le multi-touch et les gestes (y compris QML), bien qu'il ne soit que de quelques jours. complet sur Windows 7 et Mac OS X 10.6. Pendant ce temps, Canonical a travaillé avec la communauté pour développer un cadre multi-touch de bas niveau de bas niveau pour Linux et X11, au profit de Qt et d'autres boîtes à outils. Ces efforts finiront par se rejoindre au milieu.
Dans l'ensemble, je pense que Qt a beaucoup à offrir aux personnes qui veulent développer applications pour (et sur) Ubuntu, surtout maintenant. Il alimente déjà applications multiplateformes populaires comme VLC, sans parler de toute la distribution distribution Kubuntu. J'ai manqué ça quand c'est arrivé l'année dernière, mais Qt est maintenant disponible sous la LGPL 2.1 ou la GPL 3.0, ce qui devrait permettre de l'utiliser pour pratiquement toutes les applications Ubuntu. Il Il bénéficie d'un fort soutien commercial et d'une importante communauté de développeurs. Bien entendu, aucune solution unique ne répondra à tous les besoins des développeurs, et Ubuntu prend en charge plusieurs boîtes à outils et frameworks pour cette raison, mais Qt semble être un excellent outil à avoir dans notre boîte à outils pour la route à venir.
Un site Article d'Ars Technica en discutant de ce billet de blog qui donne un aperçu de la situation :
Qt peut amener les développeurs tiers à Linux
Bien que Gtk+ ait encore de la valeur et qu'il y ait un certain nombre de raisons de raisons de continuer à l'utiliser pour créer des logiciels Linux natifs, Qt est maintenant le choix évident pour les ISV qui ciblent plusieurs plateformes. Qt permet de se conformer très facilement à l'aspect et à la convivialité natifs de la plateforme sous-jacente. la plateforme sous-jacente ou de créer une interface utilisateur totalement personnalisée qui totalement personnalisée, adaptée de manière optimale à un appareil ou à un facteur de forme cible.
Au fur et à mesure que Nokia et Intel introduisent MeeGo dans une large gamme d'appareils, cela va attirer quelques grands éditeurs de logiciels commerciaux. Il serait relativement facile pour ces éditeurs de logiciels d'amener leurs applications mobiles Qt mobiles sur le bureau Linux en utilisant le même code que celui qu'ils utilisent sur MeeGo. Qt est spécifiquement conçu pour rendre cela facile. Ce serait une une énorme victoire pour le bureau Linux parce que cela apporterait des applications tierces des applications tierces qui ne seraient pas disponibles autrement.
Il convient de noter que certains fournisseurs de logiciels mobiles de premier plan sont sont déjà impatients d'adopter Qt en raison de la prise en charge de cette boîte à outils par Nokia. La société de streaming vidéo mobile Qik, par exemple, travaille sur une version expérimentale de Qt. portage expérimental basé sur Qt de son application populaire dans le but de la l'amener sur 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 du développement d'interfaces graphiques pour Linux.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
