Ok, aber dann bitte ich darum, den Begriff Windowmanager nicht mehr zu verwenden, sondern eher "GUI-Server" oder sowas zu nehmen. Dann wird das nämlich wesentlich mehr als ein Windowmanager.
Die Funktionalität für beides braucht man auf jeden Fall. Die Frage ist nur, wie man es aufteilt. Bleiben wir doch gerade mal beim Beispiel Darstellung von Schrift: Das ist eine höhere Ebene als der Grafiktreiber und gehört dort sicher nicht rein, aber es ist auch eindeutig eine Ebene tiefer als Fenster und Steuerelemente. Gerade wenn man die Konzepte klar machen will, würde ich trennen, was logisch getrennt gehört.
Von mir aus. Ich dachte es mir so, dass dieses Teil dann halt Fenster, Steuerelemente managt, gleichzeitig aber auch eine Bibliothek fuer z.B. Schriftdarstellung bereitstellt. [Ich möchte Text an ES:DI an P(x;y) gezeichnet haben, liebe FontLib.] Es ist alles eine Frage des Ziels, und ich stelle einfach mal den Sinn einer so extremen Aufteilung in Frage. Schliesslich gilt auch, dass ein extrem modulares Konzept langsamer ist, zumindest, wenn alle Module gebraucht werden.
Ich wuerde im Prinzip auf das Kerneltreiberinterface einen Treiber mit den grundlegenden Funktionen aufsetzen und schon darauf eine "riesige" Anwendung, welche die gesamte GUI darstellt, also XServer und WindowManager wuerde ich nicht trennen. Das wiederum hätte den Vorteil, dass das gesamte CommOS aus einem "Guss" gegossen ist und nicht jeder sein Sueppchen kocht. Später (viiieeelll später) könnte man das vielleicht noch aufteilen, aber ich bin wie gesagt kein Befuerworter. Ich habe nichts dagegen, aber das Konzept vom CommOS ueberhaupt ist mir noch nicht recht klar, wenn ich das mal so ausdruecken darf.
Unser OS, weil der Source das allgemeine Verständnis fuer "wie" ein OS aufgebaut ist, am Beispiel zeigt?
Schon. Aber es zeigt eben ein Beispiel aus vielen verschiedenen Möglichkeiten. Und welche dieser Möglichkeiten benutzt wird, ist zumindest mir noch nicht klar. Das kann etwas X-Server-mäßiges sein oder auch etwas Windows-artiges. Oder eine Mischung oder was ganz anderes. Aber alle diese Möglichkeiten gibt es und ein OS kann man mit jeder davon aufbauen.
Ja. Aber ich glaube, wir schiessen am Ziel vorbei bzw. darueber hinaus.
Ich meinte damit, dass es keine Steuerelemente gibt, dass jede Anwendung ihre eigenen Teile auf ein - vom WM gestelltes - Hauptfenster (Frame) raufmalt.
Ok, daß das Unsinn ist, da sind wir uns ja einig.[/quote]
Ja, aber das wuerde die GUI wieder arg vereinfachen
![Smiley :)](https://forum.lowlevel.eu/Smileys/classic/smiley.gif)
Es ist auch
eine Möglichkeit, wie man das tun kann. Und dann kann man später eine Bibliothek nachliefern, bei
der man ein Steuerelement anfordert. So könnte man z.B. alle Anwendungen ganz einfach an ein Thema anpassen (nur wenn die Libs untereinander kompatibel sind, natuerlich).
Auch wuerde ich die Steuerelemente mehr oder weniger in die GUI mit einschweissen, also nicht GTK, Qt und was es da noch so alles gibt. Es ist alles eine Frage, was das LOST denn mal werden soll. Soll es ein Linux- und Windowskompatibles OS werden? Soll es ueberhaupt zu was kompatibel sein? Wenn ja, ok. Wenn nein (was die Sache vereinfacht), so wuerde ich mich nicht um irgendwelche Toolkits scheren, sondern einfach nur einen Satz Steuerelemente in einer (austauschbaren?) Bibliothek oder gar fest eingeschweisst anbieten. Wenn eine Anwendung dann halt eigene Sachen will, soll sie diese auch komplett selbst zeichnen und benutzen. Damit wäre eine Gtk oder Qt Anwendung sicher viel schwerer zu portieren, als wenn man einfach einen solchen Ansatz wählt. Aber Einfachheit ist mir wichtiger als Kompatiblität, zumal wir ja eh alles selbst machen wollen, oder?
![Wink ;)](https://forum.lowlevel.eu/Smileys/classic/wink.gif)
Und ob ein Ereignis nun an einen grossen Grafik-Handler der Anwendung kommt oder an einen kleines eines Steuerelementes, ist schon ein Unterschied. Nämlich, wie man die Anwendung darauf abstimmen muss.
Werden die Ereignisse an das Steuerelement geliefert, so muss der Programmierer nur Häppchen hier und Häppchen da verwalten. Landen sie bei einer allgemeinen "Grafik"Routine in der Anwendung, kann der Programmierer sie alleine verteilen.
Nach oben durchreichen sollte doch kein Problem sein, wenn ich die Sache auf einer höheren Ebene bearbeiten will?
Ich bin fuer nach unten weiterreichen. Ist sicherer...
Bliebe halt die Frage, wieviel wir dem Anwendungsprogrammierer zutrauen. Soll die GUI einfach sein oder sollen die Anwendungen einfach sein? Ich bin fuer ersteres, denn es ist sicher, dass etwas einfacheres stabiler läuft. Da LOST auf eine GUI aufsetzt und nicht auf eine Konsole, ist das einer der Hauptpunkte, die dafuer sprechen.
Ich persönlich wuerde Messages an das Hauptfenster senden, denke ich. Sollte ich nen Gedankenfehler drin haben... sagt's einfach.
Und ich an das Fenster, in dem das Ereignis aufgetreten ist. Schon allein, falls man mal irgendein Linux/Unix-Toolkit portieren wollte, wäre das sehr nützlich, weil man damit gleichzeitig leicht- und schwergewichtige Toolkits unterstützt.
Mal abgesehen davon, dass ich irgendwelche Toolkits eher ungern portieren wuerde, habe ich mich vielleicht bisschen schlecht ausgedrueckt.
Wenn Steuerelemente als Fenster behandelt werden, wuerde ich dort keine Ereignisse hinschicken, sondern an das Fenster, welches die Steuerelemente "hortet". Es gibt ja auch fensterlose Applikationen...
Ich schlage vor, dass man Fenster und Steuerelemente getrennt behandelt, sie also nicht voneinander ableitet. Ein Fenster ist ein "Formular", wo man drauf zeichnen kann oder halt Steuerelemente platzieren kann. Steuerelemente hingegen können spezielle Ereignisse auslösen, welche dann an Fenster gesendet werden, sind also Transmitter.
Was die Ereignisverarbeitung nochmal angeht, so sollte sich ein Hauptfenster bei der Applikation "anmelden" und Ereignisse an eine gewisse Stelle im Code geliefert kriegen. Also dass man eine Prozedur erzeugt, welche dann vom Windowmanager aufgerufen wird.
Du meinst einen einzigen Callback für das ganze Programm? Ich hätte mir eher vorgestellt, daß ich für unterschiedliche Events unterschiedliche Callbacks habe - falls der WM was von den Widgets weiß, auch nach Widget getrennt.
Fast. Ich meinte einen Handler je Fenster (also nicht je Steuerelement, s.oben). Ich (weiss, ist kein guter Stil) teile Funktionen selten auf, wenn sie nur Kleinigkeiten machen. Also wuerde ich z.B. MouseMove, DragDrop und so weiter einfach gleichzeitig abhandeln (bzw. ignorieren) und nur gewisse Ereignisse weiterleiten wollen (>MouseClick). Wenn der WindowManager jedoch alles an verschiedene Stellen weiterleitet, setzt das mindestens leere Funktionen voraus...die ich dann halt anmelden muss. Jetzt könntest du wieder sagen, "gib doch eine Ignorierfunktion an, die nur ignoriert", aber das missfällt mir irgendwie. Ich sortiere die Ereignisse lieber selbst...
Man muss sich immer ueberlegen, ob wir ein komplexes, produktiv ausgelegtes GUI-System wollen, oder eins, welches auf Verständnis ausgelegt ist.
Svenska