Le système X Window utilise une architecture client-serveur. Le serveur X s'exécute sur la machine qui a l'affichage (moniteurs + périphériques d'entrée), tandis que les clients X peuvent s'exécuter sur n'importe quelle autre machine et se connecter au serveur X en utilisant le protocole X (pas directement, mais plutôt en utilisant une bibliothèque, comme Xlib, ou le XCB événementiel non bloquant plus moderne). Le protocole X est conçu pour être extensible et possède de nombreuses extensions (voir xdpyinfo(1)).
Le serveur X ne fait que des opérations de bas niveau, comme créer et détruire des fenêtres, faire des opérations de dessin (de nos jours la plupart des dessins sont effectués sur le client et envoyés comme image au serveur), envoyer des événements à Windows, ... Vous pouvez voir combien peu un serveur X le fait en exécutant X :1 &(utilisez un nombre qui n'est pas déjà utilisé par un autre serveur X) ou Xephyr :1 &(Xephyr exécute un serveur X intégré à votre serveur X actuel), puis en exécutant xterm -display :1 &et en basculant vers le nouveau serveur X (vous devrez peut-être configurer l'autorisation X en utilisant xauth(1)).
Comme vous pouvez le voir, le serveur X fait très peu, il ne dessine pas de barres de titre, ne minimise / iconifie pas les fenêtres, ne gère pas le placement des fenêtres ... Bien sûr, vous pouvez contrôler le placement des fenêtres en exécutant manuellement une commande comme xterm -geometry -0-0, mais vous aurez généralement un client X spécial qui fait les choses ci-dessus. Ce client est appelé gestionnaire de fenêtres . Il ne peut y avoir qu'un seul gestionnaire de fenêtres actif à la fois. Si vous avez encore ouvert le serveur X nu des commandes précédentes, vous pouvez essayer d'exécuter un gestionnaire de fenêtres dessus, commetwm , metacity, kwin, compiz, larswm, pawm, ...
Comme nous l'avons dit, X ne fait que des opérations de bas niveau, et ne fournit pas de concepts de plus haut niveau comme boutons poussoirs, menus, barres d'outils, ... Ceux-ci sont fournis par des bibliothèques appelées toolkits , par exemple: Xaw, GTK, Qt, FLTK, ...
Les environnements de bureau sont des ensembles de programmes conçus pour offrir une expérience utilisateur unifiée. Les environnements de bureau fournissent généralement des panneaux, des lanceurs d'applications, des plateaux système, des panneaux de contrôle, une infrastructure de configuration (où enregistrer les paramètres). Certains environnements de bureau bien connus sont KDE (construit en utilisant la boîte à outils Qt), Gnome (en utilisant GTK), Enlightenment (en utilisant ses propres bibliothèques de boîte à outils), ...
Certains effets de bureau modernes sont mieux réalisés à l'aide de matériel 3D. Un nouveau composant apparaît donc, le gestionnaire composite . Une extension X, l'extension XComposite, envoie le contenu de la fenêtre au gestionnaire composite. Le gestionnaire de composites convertit ces contenus en textures et utilise du matériel 3D via OpenGL pour les composer de nombreuses façons (mélange alpha, projections 3D, ...).
Il n'y a pas si longtemps, le serveur X parlait directement aux périphériques matériels. Une partie importante de cette gestion de périphérique a été déplacée vers le noyau du système d'exploitation: DRI (autorisant l'accès au matériel 3D par X et les clients de rendu direct), evdev (interface unifiée pour la gestion des périphériques d'entrée), KMS (déplacement du paramètre de mode graphique vers le noyau) , GEM / TTM (gestion de la mémoire de texture).
Ainsi, avec la complexité de la gestion des périphériques maintenant principalement en dehors de X, il est devenu plus facile d'expérimenter avec des systèmes de fenêtres simplifiés. Wayland est un système de fenêtres basé sur le concept de gestionnaire composite, c'est-à-dire que le système de fenêtres est le gestionnaire composite. Wayland utilise la gestion des périphériques qui a quitté X et effectue le rendu à l'aide d'OpenGL.
Quant à Unity, c'est un environnement de bureau conçu pour avoir une interface utilisateur adaptée aux netbooks.
