Comment les applications KDE fonctionnent-elles sous Gnome?

Si Gnome utilise GTK + et KDE utilise Qt, comment se fait-il que les applications KDE puissent s'exécuter sous Gnome?

GTK et Qt sont des boîtes à outils pour la construction d'interfaces graphiques. Chaque boîte à outils d'interface utilisateur fournit ses propres fonctions pour les programmes de création de widgets (boutons, zones de texte ...) et se présente sous la forme de bibliothèques avec lesquelles le programme graphique est lié. Un programme écrit pour GNOME utilisera GTK ( libgdket libgtk), tandis que les programmes KDE utilisent Qt ( libQtCoreet libQtGui), les programmes Enlightenment utilisent EFL, etc.

Cependant, toutes ces boîtes à outils utilisent le même système X Window et le même protocole X11 . Pour que les choses apparaissent à l'écran, la boîte à outils se connecte au serveur X en cours d'exécution (généralement Xorg, précédemment appelé XFree86), envoie des commandes X11 (créer une fenêtre, dessiner quelque chose dans une fenêtre) et reçoit les événements d'entrée X11 (souris, clavier, redimensionnement de la fenêtre , & c) de retour.

(La plupart des boîtes à outils modernes, comme GTK, Qt ou EFL, réalisent elles-mêmes des dessins de fantaisie et utilisent simplement X11 pour envoyer l'image finie de la fenêtre entière, et le serveur X la met simplement à l'écran. Les boîtes à outils plus anciennes comme lXaw ou Motif utilisent plutôt X11 pour dessiner des primitives comme des lignes ou des rectangles ou du texte, et le serveur X fait tout le rendu.)

Le serveur X fait alors le travail de tout assembler, de parler à votre carte graphique, etc. De cette façon, vous pouvez exécuter des programmes qui utilisent différentes versions différentes de différentes boîtes à outils, car au final, ils utilisent simplement les mêmes fonctionnalités du système d'exploitation.

Mécanisme, pas politique

La situation de la boîte à outils multiple n'est pas unique à X - par exemple, vous trouverez des programmes Windows utilisant la norme comctl32mais aussi WPF, .NET WinForms, Aura de Chrome, XUL de Firefox et même le même GTK ou Qt. La plupart des jeux utilisent leurs propres commandes de style. Vraiment, cela est possible sur n'importe quel système graphique qui vous permet de dessiner une image sur toute la fenêtre.

Cependant, l'un des principes de X était "mécanisme, pas politique". Cela signifie que le serveur X fournit uniquement le mécanisme permettant à ses clients (programmes graphiques) de faire diverses choses, mais impose aussi peu de règles que nécessaire . En d'autres termes, X prend cela plus largement que tout autre système graphique.

Par exemple, l'une des parties intégrantes d'un système graphique est la gestion des fenêtres - le dessin de cadres (alias décorations) autour de chaque fenêtre, la possibilité de déplacer et de redimensionner les fenêtres, etc. Windows et OS X ont un gestionnaire de fenêtres intégré au système, mais dans X il fonctionne comme un programme distinct - la suite X.Org est livrée avec un minimum twm, mais presque tous les environnements de bureau livrent leurs propres gestionnaires de fenêtres (GNOME avait Sawfish, Metacity, gnome-shell; KDE a KWin) assurant l'intégration avec l'environnement de bureau respectif.

(Comme les boîtes à outils, les gestionnaires de fenêtres modernes de "composition" prennent en charge le travail de Xorg de composer toutes les fenêtres sur l'image finale de l'écran, permettant l'ajout d'éléments comme des ombres ou des effets.)

Avec les environnements de bureau modernes, cela a également créé des problèmes. Pour utiliser l'exemple le plus courant: la même fonctionnalité "saisir le clavier" est utilisée par les raccourcis clavier; menus contextuels; et économiseurs d'écran, et un seul programme peut l'utiliser à la fois. Cela signifie que vous ne pouvez pas verrouiller l'écran alors qu'un menu contextuel est ouvert, ou sauter des chansons lorsque l'écran est verrouillé. C'est l'une des nombreuses raisons pour lesquelles Wayland est créé en remplacement du X11.

Note latérale

Techniquement, cela signifie même que vous pouvez exécuter des programmes X sur un autre ordinateur et parler au serveur X de votre machine via le réseau. En effet, c'était le premier cas d'utilisation au début, et c'est de là que vient le nom de " serveur X ". Il est possible d'exécuter un serveur X sur un Mac et de lui faire afficher des fenêtres créées par des programmes fonctionnant sous Linux, FreeBSD, même OpenVMS.

Cependant, comme mentionné ci-dessus, les boîtes à outils modernes effectuent tous les dessins côté client (les graphiques fantastiques et les jolies polices sont assez difficiles à faire avec les primitives X11), et ne poussent que les images finales vers le serveur X, ce qui est très rapide localement, mais nécessite un assez peu de bande passante réseau.

(D'autres protocoles, comme RFB (alias VNC) ou «Remote Desktop» de Microsoft, sont conçus pour cela, et ils ont des moyens très efficaces de compresser les images de la fenêtre.)

Une partie de la réponse est que les principaux environnements de bureau (Gnome, KDE, XFCE, peut-être d'autres) fonctionnent ensemble sous http://freedesktop.org pour permettre une telle interopération. L' une des spécifications publiées par FD.o est EWMH , ce qui assure un certain niveau de compatibilité entre les gestionnaires de fenêtres (pour les fonctions modernes, non seulement la gestion de la fenêtre de base).

Lorsqu'elles sont exécutées sous GNOME, les applications KDE appellent toujours les bibliothèques Qt partagées dont elles dépendent. La même chose s'applique à toute exécution d'une application sous tout autre environnement de bureau. Ils n'imposent aucune restriction sur ce qui peut être appelé et ce qui ne peut pas.