Les bureaux et GDI sur Linux

Les équivalents sur Linux, de la GDI et du bureau de Windows

Présentation…

Il est question ici des environnements de bureau de Linux, et de l’équivalent sous Linux de la GDI de Windows ( le moteur de l’environnement graphique de Windows ). Si vous ne connaissez pas, sachez que le bureau correspond simplement à l’écran principale de Windows. Il en existe heureusement sous Linux, mais loin d’êtres aussi standardisés que sous Windows… d’où la faiblesse de Linux par rapport à Windows jusque maintenant.

Présentation de la question

En plus d’être un système en kit, ce qui a tout autant jusque maintenant été un frein à la diffusion de Linux, vient aussi de la concurrence non bénéfique ( non bénéfique, car indécidable ) entre les différents environnement de bureau, aboutissant à de fastidieuses configurations pas toujours stables, des redondances inutiles… et pire encore, à des gaspillages de ressources ( démontrant une fois de plus que la gratuité logiciel se paie souvent cher en matériel ). Pour notre projet d’un Linux léger et stable, il est donc important de faire un état des lieux des bureau de Linux. Par soucis d’efficacité et d’utilité, nous nous restreindront volontairement aux deux principaux : KDE et Gnome. Tout comme la GDI est le cœur du système graphique de Windows, sans laquelle le bureau de Windows n’existerait pas, Qt et GTK, qui sont des librairie de Linux, sont tout aussi étroitement associé respectivement à KDE et Gnome. La question des librairie prendra même le dessus pour l’évaluation technique ( bien qu’à l’usage on ne voit que le bureau ).

Librairies associées à quelques applications

Vous connaissez tous et toutes les boutons, les menus, les listes déroulantes, et autres, que l’on trouve sous Windows. Sous Windows, ces petits objet qui vous permettent de communiquer avec les applications, sont créés par une librairie ( on nome ainsi un ensemble de services partagés par plusieurs programmes ) que l’on appel GDI Graphique Device Interface ). Sur les système à base de Linux, il existe deux équivalent : Qt et GTK. L’existence de ces deux système n’est pas sans poser de soucis, car certaines applications fonctionne avec l’un, et d’autre avec l’autre. C’est un peu comme si on vous disait que Windows est super, qu’il y a beaucoup de programmes intéressants sous Windows, mais sans vous dire que pour les faire fonctionner il faut avoir plusieurs versions différentes de Windows installées sur le même PC ( ce qui n’est heureusement pas le cas ). Il faudra donc faire un choix entre les deux. Mais avant de faire ce choix, je donne pour ceux et celles qui cela intéresse, une petite liste des principale applications de Linux, avec indication de la librairie graphique sur lesquelles elles sont basées.

Quelques grandes applications de Linux et leur librairie graphique
Application Librairie utilisée par l’application Domaine de l’application
AbiWord GTK Traitement de texte
Audacity GTK Traitement de son
FireFox GTK ( mais peut être compilé pour Qt ) Navigateur
GIMP GTK Traitement d’image
Gravman Qt Gravure CD
KOffice Qt Suite bureautique
Konqueror Qt Navigateur
OpenOffice.org GTK ( avant, car cette suite a maintenant sa propre librairie graphique  ) Suite bureautique
OpenWengo Qt Communicateur
Opera Qt Navigateur
Skype Qt Communicateur

Propriétés résumées

La librairie Qt est associée au bureau KDE, et GTK est associée au bureau Gnome. Voici en résumé quelques propriété liant ces bureaux et librairies. Ce résumé complétera la discussions qui suit juste ensuite.

Quelques propriétés générales et résumé…

  • Le bureau KDE est basé sur Qt
  • Le bureau Gnome est basé sur GTK
  • On peut faire fonctionner des applications Qt sous Gnome, mais le chargement est plus long
  • On peut faire fonctionner des applications GTK sous KDE, mais le chargement est plus long
  • En théorie, Qt et GTK peuvent exister sans serveur XFree ( en pratique, seul Qt le fait, avec une version sous licence commerciale )
  • La librairie wxWidget pour Linux, est basée sur GTK. Remarque : sous Windows elle est basée sur la GDI, même en présence de GTK pour Windows.
  • Qt et GTK pour Linux, ne sont pas de simple librairie graphique, mais fournissent d’autres services. En cela, elle ressemble plus à l’ensemble des DLL Windows, qu’à la seule GDI de Windows ( d’autres librairie comme FLTK et FOX sont de pures librairies graphiques, mais il n’en sera pas questions ici ).

Fonctions et fonctionnement de Qt et GTK

Les librairies GTK et Qt encapsulent la communication avec le serveur XFree, et les applications basée sur ces librairie, fonctionne donc sans se soucier du serveur graphique. Il en résulte qu’on peut parfaitement imaginer un système avec une implémentation de la librairie graphique qui ne serait même pas basé sur le serveur XFree. C’est justement ce que fait Qt, pour laquelle il existe une version autonome, qui permet de faire fonctionner des applications sans serveur XFree. Cette implémentation de Qt est basée sur les FrameBuffer de Linux ( fonctionnalité disponible à partir de la version 4 du noyau Linux ). Cette implémentation de Qt n’est pas gratuite, mais il vaut sûrement la peine de payer un peu pour s’affranchir des excessives consommations de ressources de XFree ( quelques euros de logiciel, coûtent moins cher que quelques centaines d’euros de matériel… ce que l’on oubli trop souvent ).

Les librairies Qt et GTK ne sont pas seulement des librairies graphiques, mais fournissent en sus des services réseau, des services de synchronisation de processus, des services de gestion de chaînes UTF-8, des services de prise en charge des fichiers XML, etc. Il s’agit donc bien plutôt d’un système de librairies partagées, tout à fait comparable à l’ensemble des DLL de Windows. Il est tout de même dommage que les applications en ligne de commande n’utilisent pas ces librairies ( ou que ces librairies ne fournissent pas de services pour les applications en ligne de commandes ), ce qui pourrait alléger le poids des système à base de Linux. On a deux ensembles de librairies : GLibC et GTK ou Qt. Ceci est encore une source de gaspillage, tant en terme d’espace disque que de consommation mémoire. C’est certainement une autre explication à l’excessive consommation de ressources de Linux, comparativement à Windows. Mais au moins, le problème étant identifié, il est peut-être possible de le résoudre ( en éliminant les redondances ).

Comparaison de Qt et GTK

Pour comparer Qt et GTK, on notera que Qt est mieux centralisé, et se compile mieux. GTK a d’ailleurs été abandonné par SlackWare ( si mes informations sont exacts ), à cause de ses trop nombreuses dépendances, éparses, et trop fastidieuses à gérer. GTK sert de librairies sous-jacentes à wxWidget ( une librairie graphique non-autonome et fortement dépendante ). Certaines application basées sur wxWidget, sont donc en fait par cela, qualifiée d’êtres basées sur GTK ( ce qui est effectivement le cas finalement ).

On sera intéressé(e)s par la vitesse de chargement des différents environnement de bureau… ou plutôt par la vitesse de chargement des applications sous les différents couples environnement de bureau + librairie graphique ( puisqu’il existe une relation fusionnelle entre les deux ). Le binôme KDE + Qt a la réputation d’être plus lourd que le binôme Gnome + GTK. Mais ce n’est pourtant pas tout-à-fait exact, et probablement dut au fait que les applications GTK sont plus nombreuses que les applications Qt ( mais les applications Qt, bien que moins nombreuses, semblent êtres mieux soignées, et de meilleur qualité que les applications GTK… et semblent même souvent les surpasser ). Pour comprendre l’illusion, il faut d’abord encore une fois passer par une comparaison avec Windows. Quand Windows se charge, il charge en mémoire un ensemble de librairies qui seront utiles aux applications standards de Windows. C’est le cas le plus notablement d’Internet Explorer et de RichEdit ( couche sous-jacente de WordPad entre autre ). Donc sous Windows, Internet Explorer se charge assez rapidement, parce que la plupart de ces dépendances sont déjà chargées lors l’initialisation de Windows ( ces dépendances étant partie intégrantes du système et nombreuses lui sont destinées ), tandis que Opera et FireFox sous Windows, seront plus lent à charger qu’Internet Explorer, parce qu’il devront se charger entièrement ( il n’y a aucun préchargement, ni factorisation de librairie avec le système Windows ). Il en va de même sous KDE et Gnome.

Ainsi, le chargement du navigateur Konqueror, est rapide sous KDE mais lent sous Gnome, parce que Konqueror est basé sur Qt. A l’opposé, le navigateur standard sous Gnome, qui est basé sur GTK se charge rapidement sous Gnome, mais se charge beaucoup plus lentement sous KDE ( remarquez que le monde Linux est hypocrite de dénoncer la forte intégration d’Internet Explorer à Windows, puisque KDE et Gnome en font autant ).

Avant de poursuivre, avouons qu’il est difficile de se décider entre Qt et GTK ( un choix auquel se tenir strictement est pourtant nécessaire, pour ne pas gâcher de précieuses ressources matérielles ). Qt est plus soigné, tant en terme de design que de stabilité, et cela transparaît bien dans son aspect graphique. GTK est réputé plus facile à apprendre pour les développeurs(ses). Mais n’oublions pas que ce qui doit guider les choix pour un bon système, c’est le confort de l’utilisateur(rice), et non pas celui de(de la) développeur(se) ( c’est malheureusement souvent le contraire dans les faits, et cette constatation malheureuse fera l’objet d’un article à elle toute-seule ). Les applications GTK semblent plus nombreuse que les applications Qt ( ce qui fait croire peut-être à tort que KDE est plus lourd que Gnome… car il est logiquement plus lent si on l’utilise avec des applications GTK ). Contrairement à GTK, Qt a l’avantage de bénéficier de supports commerciaux ( ce qui garantie un minimum la recherche de la satisfaction du client avant la recherche de la satisfaction du développeur… recherche du profit oblige ). Qt est mieux centralisé que GTK, et il est vrai que les dépendances de GTK ne sont pas là pour aider à rendre le système pérenne. D’autant que GTK est souvent incompatible avec GTK ( oui, vous lisez bien, GTK est souvent incompatible avec GTK ). Malgré cela, à l’avantage de GTK, soulignons tout de même que GTK semble être plus riche en fonctionnalité ( mais reste à savoir à quel prix, et à savoir si ces fonctionnalités sont vraiment pertinentes ). Il semblerait aussi que GTK soit tout de même effectivement plus léger que Qt, car factorisant plus de code avec la GLibC Qt est plus indépendante ). Mais cette dernière remarque serait sans valeur dans un environnement réduisant GLibC à son stricte minimum. Ce qui manque pour ce décider définitivement, c’est un véritable banc d’essai dans les règles, entre Qt et GTK.Ce banc d’essai devrait être attentif à l’environnement général du test, car les comportements et performances de l’une et l’autre en dépendent directement. En d’autres mots, ce banc d’essais devraient comparer ce qui est comparable, et même faire état des situations et condition de situations optimums pour chacune de ces deux librairie.

Doutes induits par la natures de ces librairies

Une chose est suspecte avec ces deux librairies : elles implémentent toutes les deux une liaison dynamique pour les méthode d’objet. Seulement, ceci ne devrait pas être du ressort d’une librairie, mais d’un langage. On peut donc s’attendre malheureusement à une surcharge inutile qui devra de toute façon être contourné si les applications doivent êtres programmées avec un langage objet digne de ce nom ( pour des raisons de fiabilité ). Apparemment, la gestion de la liaison dynamique de Qt est plus lourde que celle de GTK. Ce dernier point tendrait à faire pencher la balance en faveur de GTK. Cette surcharge de ces librairies est problématique, et ne devrait pas exister.

Un autre est celui de la pertinence d’associer ces librairie graphique à d’autres fonctionnalités. Mais dans un sens, ce n’est un problème que dans le contexte actuel ou aucune de ces librairie n’est un standard. Dans le cas contraire, on se trouverais face à un système tout aussi cohérent que Windows, et la question ne se poserait pas. Disons que l’on peut comprendre qu’une partie librairie graphique, sa couche de haut niveau, soit basé sur les autres services, et en cela on peu comprendre que tous ces éléments viennent ensemble. Ce n’est donc un problème qu’en apparence, et seulement dans le contexte actuel.