Thema: GUI-Design (technisch)

[tev]

Ich mache hier mal einen Thread über die technische Realisierung einer möglichen Tyndur GUI, welchen Namen auch immer sie bekommen wird. 

Also meine Idee, ist vergleichbar mit einem Mikrokernel OS. Denn ich stelle mir eine mögliche Realisierung so vor:
Einen Zentralen GUI Server, der die Ausgabe und die Eingabe über Maus und Tastatur.
Und dann die auswechselbaren Module, die der User theoretisch einfach nach seinen Belieben austauschen kann.

Ich geh dann erstmal auf den GUI Server ein.
Dieser Server sollte, wie ein Kernel prinzipiell so wenig Code wie möglich enthalten, den wenn er abstürzt stürzt die gesamte GUI ab. Vor allem weil, dieser eben die Ausgabe und die Eingabe verwaltet. Zum Thema Eingabe ist alles denke ich recht klar. Der Server leitet alles an das ausgewählte Fenster weiter, die er natürlich auch verwaltet. Zum Thema Ausgabe sage ich, dass sozusagen alle Module, die laufen abgeklappert werden und dann ihre Ausgabe logisch sinnvoll auf den Bildschirm gezeichnet wird. D.h. das der Bildschirmhintergrund als erstes gezeichnet wird, dann eben das hinterste bis zum vordersten Fenster und schließlich das Panel. Wobei man das bestimmt optimieren kann. 
Die Fenster werden wie gesagt vom GUI Server verwaltet, damit er auch weiß, welche Ein-/Ausgabe zu welchem Programm gehört.

Nachfolgend schreibe ich etwas zu den austauschbaren Modulen.
Die Module können eben alles mögliche sein, dass eben auf einem Desktop vorkommen kann z.B. eine Uhr, Fensterdeko, Panel, Hintergrundzeichenprogramm und ähnliches. Die Module sollten prinzipiell unabhänig voneinander funktionieren können um die GUI möglichst modular gestalten zu können, damit sie möglichst stabil läuft und vom User beliebig konfiguriert werden kann. Desweiteren sollten die Module nicht direkt mit den Grafiktreiber arbeiten müssen, was dann zu fehlerhafter Darstellung auf dem Desktop und Instabilität führen kann. So sollte es eine Art libGUI zwischen den Modulen und dem GUI Server geben.

Ich hoffe es war alles soweit verständlich und alles was hier steht sind meine Ideen und, weil ich Morgen leider nicht an der Designdiskussion teilnehmen kann poste ich es hier, damit es genauso diskutabel ist.

Und genauso kann die Community hier ihre Designtechnischen Ideen posten/einbringen.

Gruß tev

[SHyx0rmZ]

Zur Eingabe: Der Server sollte die Daten eben NICHT direkt zum Fenster durchleiten. Den Ansatz scheinen einige Fenstersysteme ursprünglich eingeschlagen zu haben, dementsprechend schlecht funktionieren da IMEs. Ich würde mir wünschen, dass zumindest die Möglichkeit einer Inputverarbeitung durch Module eingebaut wird.

[Svenska]

Ich hatte eine recht ausführliche Diskussion mit FlashBurn zu dem Thema, bitte guck dir die auch an (zu finden hier). Ab Seite 3 geht es um Grafik, der Rest ist eigentlich nur für Textmodus (und Textmodus-in-GUI), also hier weniger relevant.

[oern]

Ich denke, dass die GUI einen Mausklick etc. nur dann weiterleitet, wenn er auf dem gerade aktiven Fenster stattfindet. Wenn man auf das X klickt (oder wie man eben ein Fenster schließt) oder auf ein inaktives Fenster klickt, umes zu aktivieren, hat das Programm selbst damit ja nichts zu tun.

[DeepDancer]

Ich denke, dass die GUI einen Mausklick etc. nur dann weiterleitet, wenn er auf dem gerade aktiven Fenster stattfindet. Wenn man auf das X klickt (oder wie man eben ein Fenster schließt) oder auf ein inaktives Fenster klickt, umes zu aktivieren, hat das Programm selbst damit ja nichts zu tun.

Das stimmt so nun aber auch nicht ganz...
Wenn ich versuche ein Fenster zu schließen wird der Klick auf das "X" sehr wohl von dem zu beendenden Programm verarbeitet. In Delphi gibts da dann zum Beispiel ein "OnCloseClick", in vielen (wenn nicht allen Programmiersprachen) sind Äquivalente (hab ich das nu richtig geschrieben  ) vorhanden.

Auch das aktivieren inaktiver Fenster gibt es in modernen BS so ja nicht mehr. Wenn ein Fenster nur zum Teil verdeckt ist reagiert dieses sehr wohl auf Mausklicks in den sichtbaren Teil (Menüs werden geöffnet nachedem das Fenster in den Vordergrund geholt wurde).

Also soooo trivial wie sich viele das immer vorstellen ist die Sache auch ned ganz 

[oern]

@DeepDancer: In MacOS X wird das Programm auch nicht durch schließen eines Fensters beendet, sondern durch die Tastenkombination Cmd+Q oder im Programmmenu.

[DeepDancer]

Najanuuu, das ist jetzt aber ein sehr spezieller Fall würd ich denken 

Unter Mac hab ich selber auch noch nix gemacht, ich wollte nur verdeutlichen, dass die Aussage "hat das Programm selbst damit ja nichts zu tun" etwas genauer beleuchten. Und so nen Fenster interessiert es halt im allgemeinen schon wenn ne Aktion darauf durchgeführt wurde. Auch das in den Vordergrund holen löst ja bei dem jeweiligen Fenster durchaus Aktionen aus, und wenn es nur das neuzeichnen desselben ist ...

[stultus]

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.

[PNoob]

wie meinst du das jetzt mit den Subfenstern? so kleine Boxen die sich in den Fordergrund des Programmes legen und Fehlermeldung beinhalten. so ähnlich wie die lustigen kleinen Fenster denen man unter Windows öfters mal begegnet, wo nur nen OK zum anklicken ist und dort kein Text steht?

uns ansonsten fände ich es sinnvoll, wenn man die Fensterverwaltung und das auf den Bildschirm zeichnen abstrahiert, also voneinander trennt. damit man SPÄTER mal ähnlich wie beim XServer unter Linux Die Fenster einzelnt oder alle auf einem anderem PC darstellen kann. also ähnlich dem X Forwarding bei ssh

PNoob

[kevin]

Mit Fenstern und Subfenstern ist erstmal gar nichts sichtbares gemeint, sondern eine Hierarchie von Flächen, auf die gezeichnet wird, die Ereignisse empfangen usw.

[PNoob]

achso also buttorns und so?

[kevin]

Ich weiß, Lesen ist schwer. Versuch's trotzdem mal:

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 .

[stultus]

Mit Fenstern und Subfenstern ist erstmal gar nichts sichtbares gemeint, sondern eine Hierarchie von Flächen, auf die gezeichnet wird, die Ereignisse empfangen usw.

Fasst das doch ganz gut zusammen.

Und ein Dialogfenster wäre ein normales Kindfenster - das in einem Teilbereich laufen lassen wäre irgendwo doof, schließlich möchte man die vielleicht auch mal verschieben, sollen eine eigene Deko haben, ...

Normale Fenster -> quasi sichtbare
Subfenster -> _teile_ des Elternfensters, die eigenständig behandelt werden.

[kevin]

Eigene Dekoration verbietet ein Subfenster ja nicht. Die einzige Einschränkung wäre, dass man es nicht aus dem Elternfenster hinausverschieben kann. Was manchmal durchaus gewollt sein kann (wäre aber eine Policy, die eher der WM vorzugeben hat).

[FreakyPenguin]

Ihr könntet eventuell auch mal einen Blick auf Wayland werfen, sowohl wegen dem Protokoll als auch wegen dem Design. Das ganze scheint ja relativ einfach gehalten zu sein. Wenn da vielleicht später sogar etwas Kompatibles drin wäre würde das wohl einiges an Arbeit beim Portieren von irgendwelchen Toolkits/Applikationen sparen.