Fenstersystem

(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
Der Displayserver (in der Grafik als Wayland Compositor bezeichnet) ist eine zentrale Komponente eines Fenstersystems.
(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
Typische Elemente eines Fensters; Die Fensterdekoration kann entweder von dem Fenstermanager gezeichnet werden (z. B. X11) oder von einem Klienten (z. B. KWin). Der Fensterinhalt ist stets die Domäne des Klienten.
(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
Fenstersystem-basierte grafische Benutzeroberflächen haben mehrere Komponenten, z. B. Gnome-Shell auf Mutter und X.Org-Server

Ein Fenstersystem (englisch windowing system) ist der Unterbau einer grafischen Benutzeroberfläche (GUI), deren Hauptaufgabe die Verwaltung von Programmfenstern ist. Im Normalfall ist es Teil einer größeren Desktop-Umgebung.

Aus der Sicht eines Programmierers implementiert das Fenstersystem die grafischen Basisfunktionen, wie das Darstellen von Schriftarten, Zeichnen von Linien, Kurven und Pixelgrafiken, und das Abstrahieren der Grafikhardware (Grafikkarte).

Das Fenstersystem gestattet es dem Anwender mit mehreren Programmen gleichzeitig zu arbeiten, indem jedes Programm „in“ einem oder mehreren eigenen Bereichen des Bildschirms, den Fenstern, ausgeführt wird, die üblicherweise rechteckig sind, mit dem Zeigegerät (Maus) frei bewegt werden können und einander überlappen dürfen.

Einige Fenstersysteme, wie das X Window System in Unix-artigen Umgebungen, haben erweiterte Fähigkeiten wie Netzwerkstransparenz, die es dem Anwender gestatten die grafische Oberfläche einer Anwendung auf einem anderen Computer darzustellen. Das X-Window-System implementiert auch kein festes Aussehen der Umgebung, wodurch die Fenstermanager, GUI-Toolkits und Desktop-Umgebungen volle Freiheit bei der optischen Gestaltung und Handhabung haben.

Liste von Fenstersystemen

Siehe auch

Auf dieser Seite verwendete Medien

Wayland display server protocol.svg
(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
en:Wayland (display server protocol)
① The en:evdev module of the en:Linux kernel gets an event and sends it to the en:Wayland compositor. This is similar to the X case, which is great, since we get to reuse all the input drivers already in the kernel.
② The Wayland compositor looks through its scenegraph to determine which window should receive the event. The scenegraph corresponds to what's on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
③ As in the X case, when the client receives the event, it updates the UI in response. But in the Wayland case, the rendering happens in the client, and the client just sends a request to the compositor to indicate the region that was updated.
④ The en:Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an en:ioctl to schedule a pageflip with KMS