Fenstersystem
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
- 8½ und rio für Plan 9
- GEM
- PC/GEOS (Graphic Environment Operating System, das Fenstersystem für Commodore 64 und 128)
- Fresco/Berlin
- FBUI
- Qt Extended (vormals Qtopia)
- Quartz Compositor für macOS
- X Window System (Freie Software, De-facto-Standard in Linux und anderen Unix-artigen Betriebssystemen)
- Wayland
- Mir
- Windows Presentation Foundation
- Xynth
- ManaGeR (MGR)
- Twin (Text Window Manager)
- Fenstersysteme für das Web:
- Dojo
- TIBCO General Interface – ein Open Source Ajax Internet Application Toolkit
- WebWM, Web Window Manager
Siehe auch
Auf dieser Seite verwendete Medien
(c) Shmuel Csaba Otto Traian, CC BY-SA 3.0
Schema der Schichten der Grafische Benutzeroberfläche
(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