Imho sollte der GUI(-Dienst) (wirklich ähnlich einem Mikrokernel) in erster Linie delegieren. d.h.,
a) Fenster verwalten (Hierarchie, aktuelle Positionen, Überlagerungen, ...)
b) Eingaben annehmen und ggf. auswerten (soweit sinnvoll), Eingaben in Ereignissen verpacken.
c) Ereignisse den Fenstern zustellen.
Fenster zeichnen sich in erster Linie dadurch aus, das sie
- grafische Ausgabemöglichkeit haben, entsprechend ihrer Dimensionen
- Ereignisse annehmen können (oder müssen), und ggf. entsprechend reagieren
- durch Position, "Erbreihenfolge" (Eltern/Kind-Fenster) und Z-Index eine klare Reihenfolge bieten
- "Sub-Fenster", d.h. Fenster ohne eigenen Bereich, die stattdessen in einem Teil ihres Elternfensters arbeiten.
Ein normales (gesehenes) Anwendungsfenster wie man es jetzt z.b. in jeder Oberfläche sieht, wäre also zuerst einmal ein "normales" Fenster das von oberster Ebene abstammt. Hier wäre dann die gesamte Fensterdekoration untergebracht, Klicks auf das (X) z.b. würden von diesem Fenster verarbeitet werden. Der eigentliche Inhalt, der von der Anwendung definiert wird, wäre dann ein Subfenster - das seinerseits weiter unterteilt sein kann, z.b. in einzelne (Sub)fenster für Buttons, Texteingabeelemente, etc. Man beachte, _Möglichkeit_, man muss es nicht so machen, man könnte genausogut alles in einem Fenster belassen und mit vielen Koordinatenvergleichen arbeiten
.
Das einzig wichtige hierbei ist halt, das die Ereignisbehandlung fuer jedes dieser Fenster individuell genug festgelegt werden kann. Die GUI muss sich letztendlich nur darum kümmern, das ein Ereignis an den (oder die) besten Treffer weitergereicht wird, vorzugsweise indem ein Fenster signalisiert welche Ereignisse es verarbeiten kann bzw empfangen möchte.
Infrastrukturell würde das dann reichen um eigentlich auf beliebige Art&Weise dadrauf alles weitere aufzubauen. Window Manager, kann im GUI-Prozess sein, aber auch ausgelagert werden (Gehört das Fenster halt nem andern Prozess). Sowas wie Eingabeelemente, könnte entweder auf Anforderung innerhalb der GUI erzeugt werden, oder eben außenstehend durch eine Toolkit-Bibliothek.
Was die Ausgabe angeht, ist es meiner Meinung nach sowieso unumgänglich das Anwendungen auch direkt an den Grafiktreiber kommen, bzw. halt genau so nah dran wie der GUI-Prozess auch - andernfalls müsste alles was an Daten auf den Monitor gebracht werden soll durch den weiteren Prozess getunnelt werden, evtl. vorhandene Hardwarebeschleunigung könnte nicht genutzt werden - alles sehr ärgerliche Einschränkungen für die Performance, die (leider) unter einem Microkernel sowieso schon etwas leidet.
Stabilitätsprobleme können dadurch natürlich prinzipiell schon entstehen - aber auch nur wenn man grobe Fehler macht und seine Daten nicht entsprechend validiert. Aber das ist ein eher grundsätzliches Problem das immer auftaucht wenn Daten ausgetauscht werden. Oder rein praktisch betrachtet: Dem Benutzer ist es egal, was da abstürzt, ob GUI-Dienst oder Grafiktreiber oder sonstwas. Möglich ist das überall.
Was den Darstellungsaspekt dabei angeht: die Darstellung bleibt konsistent, solang alles aus einem Guss kommt. Nur weil man die Grafikhardware der Endanwendung zur Verfügung stellt heißt das ja nicht das diese die Möglichkeiten auch sofort nutzen muss um alles selber zu machen, stattdessen könnte eine Bibliothek die Arbeit übernehmen die von der Anwendung verwendet wird. Und _falls_ eine Anwendung dann letztendlich davon abweicht, wird das in der Regel seinen Grund haben.
Soweit mein Vorschlag zum "grundsätzlichen" Mechanismus hinter einer GUI. Ob man den Windowmanager und Toolkits fuer die "High-Level"-Elemente (Buttons etc) nun im GUI-Dienst oder in weiteren Prozessen&Bibliotheken implementiert ist dafür letztendlich unerheblich.
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Beiträge anzeigen