Windows vous offre une seule implémentation d'un seul bureau en plus d'une seule implémentation d'une seule API / infrastructure, le tout fait par Microsoft.
Sur les systèmes Unix, vous obtenez une API / framework (X11 / X Window System) pour lequel existent plusieurs implémentations (Xorg, Xfree86), en plus desquelles vous obtenez diverses API / frameworks "de plus haut niveau" (GTK +, Qt, ... ) parce que le X11 brut est si primitif, au-dessus duquel vous disposez de divers bureaux (Gnome, KDE, ...), tous réalisés par des personnes différentes.
De plus, le système X11 a été conçu dès le départ avec des interfaces graphiques distantes à l'esprit - c'est-à-dire une machine lokal affichant l'interface graphique d'une application exécutée à distance - qui introduit les concepts de "X Server" et "X Client".
Ensuite, il existe une nomenclature qui "se sent" dans le mauvais sens pour les nouveaux arrivants: votre machine locale exécute le "X Server" fournissant le service "afficher une interface graphique", tandis que la machine distante est le "client X" faisant usage des services sur votre machine pour afficher l'interface graphique.
Eh bien, c'est un bref aperçu; une fois que vous avez trié cela, la compréhension des articles / messages du forum sur le sujet devrait devenir beaucoup plus facile.
Edit: Répondre aux deux premiers commentaires du PO.
Oui, "X11" n'est qu'un protocole, et Xorg / XFree86 sont deux implémentations. À son niveau de base, X11 ne concerne que le dessin de lignes et de points, ce qui n'est pas très utile si vous voulez faire une interface graphique.
En plus du protocole X11, les gens ont implémenté beaucoup de choses, et il est assez difficile de faire une comparaison 1: 1 avec Windows car Microsoft n'a jamais pris la peine de vraiment séparer les choses. De plus, je ne suis pas un développeur de type GUI, c'est-à-dire que mon expérience réelle avec l'un ou l'autre système est minime.
En bas, un "gestionnaire de fenêtres" fournit une fenêtre (gestion des bordures, fermeture / minimisation / maximisation des boutons, redimensionnement, etc.), et offre "l'immobilier" dans la fenêtre au jeu d'outils de widget. Il existe de nombreux gestionnaires de fenêtres, certains imitant d'autres systèmes (Windows, MacOS, AmigaOS, peu importe), et ils sont généralement interchangeables et transparents avec le système restant.
Le "widget toolset" vous propose des boutons, des curseurs, des champs de texte, etc. sur lesquels construire votre interface graphique. C'est ce que vous (en tant que développeur d'applications) pouvez réellement "voir", en termes d'API, et ce qui décide de la plupart du "look & feel" de votre application.
Un «bureau» construit un certain nombre d'applications au-dessus d'une certaine combinaison d'outils de widget / gestionnaire de fenêtres, afin de fournir une apparence cohérente. Vous n'avez pas à vous en préoccuper, sauf si vous souhaitez réellement développer le bureau lui-même.
Le bureau "Gnome" utilise le jeu d'outils de widget "GTK +" en haut du gestionnaire de fenêtres "Metacity".
Le bureau "KDE" utilise le jeu d'outils de widget "Qt" en haut du gestionnaire de fenêtres "KWin".
Notez que ces deux derniers, GTK + et Qt, ont évolué bien au-delà des simples "jeux d'outils de widgets" en "cadres de développement d'applications". Si vous souhaitez développer des applications GUI pour Linux, vous devez effectivement choisir laquelle de ces deux vous souhaitez utiliser. Il y a plus de choix, si vous voulez une application plus "légère" (ne nécessitant pas les grandes dépendances de bibliothèque), mais aujourd'hui la plupart des systèmes ont des bibliothèques GTK + et Qt déjà installées de toute façon.
Il est parfaitement possible d'utiliser des applications Qt sur un bureau Gnome ou des applications GTK + sur un bureau KDE (ce n'était pas toujours comme ça), vous n'avez donc pas à vous soucier de la compatibilité. Étant donné le choix entre deux applications de fonctionnalités comparables, les gens préfèrent généralement l'application en utilisant les widgets "natifs" de leur bureau de choix, mais je ne m'en inquiéterais pas.
Autres puces plus importantes dans le choix du "jeu d'outils de widgets": conditions de licence, prise en charge de la langue de votre choix, compatibilité multiplateforme.
Post Scriptum : En revenant plusieurs années plus tard, j'ai acquis ma propre expérience de programmation GUI et je me rends compte qu'une chose manque dans l'explication ci-dessus si vous cherchez un conseil "dans quelle direction aller": wxWidgets . Il s'agit d'un cadre qui s'appuie sur tout ce que vous utilisez en mode natif et permet un développement graphique transparent et portable , sans sacrifier les performances ni avoir de chaînes de licence. API C ++. C'est le chemin que j'ai choisi pour mes besoins en GUI, et j'ai pensé qu'il devrait être mentionné pour être complet.