Qt ou GTK

Qt qui s’écrit comme je viens de le faire, et surtout pas QT comme beaucoup de français le font. Cela veut dire qu’ils ne comprennent même pas ce que cela veut dire, en effet Qt se prononce « cute » et qui signfie mignon. GTK s’écrit comme je viens de le faire car c’est un acronyme pour Graphic Tool Kit.

Les deux « outils » permettent de créer des interfaces utilisateurs graphique (GUI), c’est à dire des fenêtres en gros, avec tout ce qu’il faut dedans (bouton, case à cocher, etc). GTK est créé à l’origine pour GIMP, Qt a été développé par Trolltech et est à présent dans les mains de Nokia. Qt possède une license commerciale mais aussi Open source pour les projets libres.

Qt est utilisé par KDE, c’est l’outil principal utilisé pour les fenêtres, et GTK est utilisé pour Gnome. Cela donne l’impression qu’une application GTK ne fonctionnera pas sur KDE et réciproquement (une application Qt sur Gnome). C’est faux heureusement, sauf si l’application utilise des fonctionnalités propres à l’environnement de bureau (par exemple KatePart qui est un composant de KDE comme on a pu le voir tout à l’heure). Par contre il va y avoir une différence de rendu visuel: le thème. Une application GTK sera moche sur KDE, et une application Qt sera moche sur Gnome… ou pas. Qt 4+ est cute sur beaucoup d’environnements, dont Gnome. Il s’adapte parfaitement, à quelques exceptions prêts. Par contre GTK est moche de partout, sauf sur Gnome. Même sur Windows, c’est moche, mal intégré, mais ça marche et c’est l’essentiel (sauf pour le grand public). Bon ce n’est pas toujours si moche, pidgin est assez correct mais on sent qu’il est différent des autres applications KDE.

Un autre problème est si vous êtes sur KDE par exemple, et que vous voulez utiliser une et seulement une seule application GTK, il va falloir télécharger tous les paquets GTK. Cela représente des mégaoctets, juste pour une seule application. C’est d’ailleurs également valable pour Windows, à la différence sur linux, c’est que cela fonctionne par paquet, qui eux sont dépendants de la distribution, et si la distribution est pourrie alors GTK a mal été packagé et l’installation de GTK peut faire plusieurs centaines de méga. C’est réciproque pour Qt pour un environnement Gnome, alors la solution consiste à utiliser une meilleure distribution.

Sur linux il y a donc des trolls entre Qt et GTK, de qui est mieux, du pourquoi, du comment. Que Qt est maintenu par Nokia et non par la « communauté » (pas de l’anneau). Mais d’un autre coté cela stimule la compétition, tout en fragmentant les applications: il y a généralement deux versions d’une application: une en Qt, une en GTK, quand ce n’est pas 50 en Qt, 50 en GTK, et 25 avec des toolkits nouveaux ou exotiques.

Lequel est mieux, lequel est pire ? Généralement avec cette question facheuse, le camp qui se sent du coté du pire va tout simplement répondre: il y a des besoins différents… qui est pourtant le même: afficher une fenêtre et des boutons. Derrière cela se cache d’autres raisons, si c’est Qt le pire:

  • soit parce qu’on a pas envie d’apprendre un nouvel outil par fénéantise ou par manque d’utilité (à quoi bon connaître deux outils identiques)
  • soit parce qu’on aime pas Qt
  • soit parce qu’on est dans l’idéologie libriste et on refuse de toucher à Qt car c’est Nokia qu’il le gère (note: mais accepte les contributions externes)
  • soit parce que c’est pour le plaisir de la diversité
  • soit parce qu’on a participé à GTK et qu’on ne le laissera pas tomber par principe

ou toutes autres raisons auxquelles je ne pense pas actuellement. Pour GTK c’est la même chose, sauf pour l’idéologie libriste. Pour ma part, j’ai du mal à comparer les deux, je me suis servi de GTK à l’université et j’ai détesté, et je me suis servi de Qt et j’ai accroché. La notion Signal/Slot est très puissante, bien que l’on retrouve presque la même chose dans GTK, mais surtout Qt est un framework plutot qu’un simple outil dédié à l’UI, qui du coup peut sembler plus lourd mais il est découpé en module et permet de faire beaucoup plus de choses en beaucoup moins de lignes. Le framework Qt est cross-plateforme, utiliser ce que fourni le framework est alors préférable pour faciliter le portage.

Voici deux applications que j’apprécie et qui fonctionnent aussi bien sur Windows que Linux: Mumble et KVirc. Une application bien utile en GTK était aMSN, entièrement mal intégrée quand utilisée sur Windows, et pire sur KDE.

Publicités

Kate, KWrite, KDevelop, KatePart

Kate est le parfait exemple de projet raté. Plus précisément KatePart qui est un moteur d’affichage de texte, qui est utilisé ensuite par Kate, mais aussi KWrite et plus généralement n’importe quel logiciel qui a besoin d’afficher du texte coloré (du code source en général) comme KDevelop. Je pense que c’est le parfait exemple du pourquoi linux n’est pas encore prêt pour le grand public.

KatePart est une brique essentielle de l’environnement de bureau KDE puisque beaucoup de programmes vont se reposer dessus pour afficher une zone d’édition de texte. Pour les connaisseurs, on peut voir KatePart comme en gros un équivalent de Scintilla. Il peut ainsi être utilisé dans d’autres applications de manière très simple grâce aux interfaces KTextEditor qu’il implémente (l’API).

Je ne vais pas entrer dans le détail puisque l’équipe a rendu public ce problème sur leur site officiel. Ce qui est une bonne chose de reconnaître publiquement les problèmes d’un projet, et ainsi comprendre les erreurs pour ne plus les refaire. Le problème a été introduit lors de la migration vers Qt4, donc aussi de KDE3 vers KDE4. Quelques phrases clefs:

« The implementation is really complex and rather undocumented in most areas. ».
« It’s far too complex to make the KTextEditor interfaces thread-safe… »
« this shows that multi-threading simply complicates the matter a lot. »
« Hence, the current API is unfortunately pretty much broken by design. »

Bref, une mauvaise conception… Es-ce que cela peut se résumer à: « Ca à l’air bien, on fonce, on regarde ce que ça donne. » et ce à l’échelle d’une interface critique ?

La phrase de fin de l’article peut presque résumer la situation: « So maybe the issues above are a necessary step to a much better implementation » qui se comprend naturellement, c’est en faisant des erreurs que l’on apprend et améliore. Cependant, la coloration de lettres, de mots, de portions de texte, ne date pas d’aujourd’hui. Les usages que l’on peut en faire ne sont pas nouveau non plus, cela fait plus de 15 ans que les IDE existent (Delphi en 1995 par exemple). D’autant plus qu’afficher du texte, éventuellement coloré, c’est la base, KatePart est une brique fondamentale de KDE.

L’article date du 28 avril 2010, à cela on ajoute le temps de correction et autre, donc c’est fin 2010 que l’on a pu profiter de l’évolution, et durant toute cette période les rapports de bugs ont été classé en WON’T FIX (« ne sera pas corrigé). Et le downgradage était peu envisageable puisqu’il fallait retourner à KDE3 (l’API ayant changé), ou sinon utiliser la version git et c’est ce que j’ai fais.

Mon coté utilisateur a été extrêmement déçu, qu’en l’an 2010 je me sois retrouvé dans une situation de non-production à cause d’un problème d’éditeur de texte. J’utilise Arch linux pour avoir les versions de release les plus récentes, et pourtant pendant plusieurs mois cela a été bloquant. Il existait des solutions comme je l’ai indiqué, mais cela ne change rien au problème qui est que pendant plusieurs mois une version buggée de KatePart était en production (et aussi sur toutes les distributions qui utilisaient cette version), impactant les applications qui en dépendent (comme KDevelop).

Mon coté développeur a été encore plus déçu en voyant la réalité des choses.

  • Déjà, la « qualité » du code, digne d’une entreprise qui a fait codé la chose dans l’urgence et par un seul développeur. En fait dans tous les projets open source dont j’ai mis les mains, le code était vraiment pourri et déroutant (cf update-mime-database)
  • Ensuite, un composant critique, au coeur d’un environnement de travail (KDE), complétement mal pensé: aussi bien l’interface KatePart qui imposait l’utilisation abusive de signaux, que l’implémentation qui se voulait être thread-safe.
  • Une méthode de travail pas digne d’un projet qui a pour vocation d’être maintenu par d’autres, mais cela rejoint le premier point sur la qualité du code et documentation.

Pour résumer: une plus grosse déception.

Cela rejoins le problème essentiel de linux: cela a été codé pour résoudre un problème personnel: que ce soit KatePart codé pour des documents faiblement coloré, faisant donc planté une IDE comme KDevelop. PHP a été codé pour un besoin personnel… et a été codé n’importe comment: un ensemble d’outils perl à l’origine, puis couplé à du C, puis pour être entièrement recoder pour la version 3 de PHP. D’un certain coté, PHP date de 1995, par opposition à KatePart dont les besoins auxquels il était amené à répondre était connus depuis fort longtemps.

Bref, une majorité de programmes du monde de linux sont écrit par passion, et donc pour répondre avant tout au besoin de celui qui l’écrit. Cela peut être mal fait, donc il y a des ré-écritures (combien de voir j’ai pu voir ça dans des releases), ou alors c’est forké car l’auteur souhaite conserver son code pourri. Du coup linux c’est la diversité car chacun aime faire différemment, ou faire sa propre implémentation, car puisqu’il y a beaucoup d’étudiant, ils aiment bien refaire les choses pour les découvrir et les comprendre.

C’est la différence du monde propriétaire, où le besoin de l’utilisateur passe avant le besoin du développeur, dont en général le développeur n’aime pas ce qu’il fait et le fait car il est payé (mais il ne faut pas généraliser n’est-ce pas).

Ne pas généraliser

L’article précédent est une exagération, le développeur (de update-mime-database) avait quand même prévu des cas d’erreurs bien sûr mais il avait oublié de vérifier les données en entrée. Cela n’entre pas dans la catégorie « bug normal » car les bugs ça arrivent à tout le monde, mais plutot dans « erreur » car la vérification de données en entrée est indispensable.

De plus, c’est normal que le logiciel soit fourni sans garantie. Le logiciel propriétaire ne fait pas mieux, il suffit de lire les EULA (End User License Agreement) de Windows par exemple:

L’obligation intégrale de Microsoft et de l’un ou l’autre de ses fournisseurs aux termes de toute disposition du présent EULA et votre recours exclusif à l’égard de tout ce qui précède (…) se limite au plus élevé entre les montants suivants: le montant que vous avez réellement payé pour le Logiciel ou 5,00 $US.

Donc si le pire se produit, au mieux vous êtes remboursé. Avec le logiciel open source et gratuit, il n’y a rien à remboursé puisque rien n’a été payé. Donc la réelle différence, ce sont les 5 dollars minimum. A vrai dire, j’ai lu l’EULA de Windows 7 disponible ici (du formulaire: home premium fr) et je ne retrouve pas la trace de ces 5 dollars, peut-être que ce n’est qu’au Canada en fait. Du coup du point de vu garantie, ce n’est pas mieux, c’est à égalité même. Dans le détail il y a une garantie limitée mais je ne vais pas entrer dans le détail, le PDF est clairement lisible, il n’est pas écrit entièrement en majuscule comme certains EULA, et il est facilement compréhensible. Le résumé est juste le suivant: pas de différence en pratique entre Windows et Linux.

Pour revenir à linux, si il ne faut pas généraliser, ce n’est pas pour autant un cas isolé. Le problème de linux (les logiciels) est avant tout qu’il est écrit par des débutants. C’est en étant étudiant que Linus Torvalds a commencé Linux, es-ce que tous les étudiants code n’importe comment ? ça dépend si ils ont de l’expérience ou non… donc en général oui. C’est une bonne et une mauvaise chose à la fois, car c’est essentiellement des étudiants qui consacrent beaucoup de temps à coder gratuitement. Ils apprennent de leurs erreurs heureusement, ils s’améliorent, puis deviennent professionnel après avoir obtenu leur diplôme et foutu la merde dans linux. Ok, c’est exagéré…

Heureusement que c’est moins grave que ce que l’on peut croire, linux comme on l’a vu est composé de différentes parties, dont le noyau, c’est le coeur du système, et n’importe qui ne peut pas mettre en production son code dedans sans une assurance qualité. Mais cela ne signifie pas qu’aucun étudiant n’a déjà fourré son nez dedans ou amélioré la chose.

Par contre, pour tous les autres logiciels, le contrôle qualité est au bon vouloir des personnes qui s’occupe du projet. Et cela y compris au niveau des environnements de bureau. A différent degrès quand même, mais par exemple, un logiciel hébergé sur les serveurs KDE, au même niveau des sources de KDE, peut être une vraie merde. Par contre j’espère que les composants critiques de KDE sont pris plus au sérieux, mais je ne saurai le dire.

Nous avons alors un noyau solide et des logiciels buggés autour. Moins il y a de logiciel autour, moins il y a de bugs, et c’est le cas des serveurs linux, sans environnement de bureau, on réduit considérablement les problèmes. Les serveurs linux sont très fiables pour cette raison: un noyau solide avec des applications serveurs qui ont fait leur preuve. Par contre mélanger la fiabilité des serveurs avec la fiabilité du desktop (l’environnement de bureau), c’est être aveuglé par l’idéologie du libre. Et un exemple sera donné bientôt.