Lowlevel
Lowlevel => tyndur => Thema gestartet von: Golum am 19. May 2005, 15:43
-
Ich habe mir mal einige wenige Gedanken zur GUI gemacht.
Die GUI zeichnet über einen "Grafik-Server" auf den Bildschirm.
Wenn der Kernel eine Eingabe erhält die auf die GUI einwirkt (Tastendrücke etc. ) fügt er die einer Message-Queue zu, von Zeit zu Zeit arbeitet die GUI die ersten x einträge ab. Falls die Queue voll ist werden einfach keine weiteren eingaben akzeptiert.
Die GUI wird als Anwendung laufen (vergleichbar mit X unter Linux).
Was vielleicht noch zu ändern wäre ist das die GUI eingaben direkt abfragt aber dann müsste sie als Kernel-modul laufen.
Vorschläge sind natürlich gerne gesehen :D
-
Was vielleicht noch zu ändern wäre ist das die GUI eingaben direkt abfragt aber dann müsste sie als Kernel-modul laufen.
Ich persönlich nehme sowieso immer weiter Abstand von einem echten Microkernel. Aber ich steh recht alleine da :-(
-
Hi,
mir gefällt diese Idee! Hört sich zumlich guit an!
Falls die Queue voll ist werden einfach keine weiteren eingaben akzeptiert.
Nur das find ich nicht so gut! Wie viele Einträge soll es da dann geben können? Wenn, dann müssten des schon so viele sein, das sie bei normalem gebracuch nicht vill werden kann, sonst will man ein Fenster verschieben, da dieser eintag abe nicht mehr rein geht, kann man das net machen, ...
von Zeit zu Zeit arbeitet die GUI die ersten x einträge ab
Was meinst du mit von Zeit zu Zeit?? Dess sollte schon zügig ablaufen!
Und zu letzt noch eine kleine Frage:
Hat jedes offene Fenster seine eigene Message-Queue oder gibt es eine für alle Fenster zusammen?
-
ich persönlich würde die GUI als seperates Prog einrichten, das man aufrufen kann. So wie es bei Linux ist, oder bei Win3.11 war.
Hätte den Vorteil, daß der Kernel nicht weiter beladen wird, und fehler nicht den kernel stören, bzw. auch die Entwicklung der GUI seperiert werden kann.
Ist aber "nur" meine Meinung.
P.S.: Wäre sowieso toll, wenn der Kernel möglichst schnell ein funktionierendes Dateisys unterstützt, und dann um Funktionalität mittels Dateien eerweitert werden kann. (Weiß allerdings nicht wie viel Arbeit das alles ist. Bin noch immer Anfänger :-( )
Gruß sov21
-
Falls die Queue voll ist werden einfach keine weiteren eingaben akzeptiert.
Nur das find ich nicht so gut! Wie viele Einträge soll es da dann geben können? Wenn, dann müssten des schon so viele sein, das sie bei normalem gebracuch nicht vill werden kann, sonst will man ein Fenster verschieben, da dieser eintag abe nicht mehr rein geht, kann man das net machen, ...
Vielleicht hat irgendein böses Progrämmchen ne Endlosschleife die die Queue immer weiter auffüllt. Das System würde überlastet werden. Das ist schon gut so wie Golum das machen will ^^
von Zeit zu Zeit arbeitet die GUI die ersten x einträge ab
Was meinst du mit von Zeit zu Zeit?? Dess sollte schon zügig ablaufen!
1. Hat die GUI auch noch andere Sachen zu machen
2. Gibts mehrere Anwendungen die abgearbeitet werden sollen
3. Siehe oben
-
Das Problem das du bei normaler verwendung keine eingaben mehr machen kannst wirst du sicher nicht haben :D
Von Zeit zu Zeit wird wahrscheinlich sehr sehr oft sein (Nach jedem Abarbeiten der anfallenden aufgaben)
Hat jedes offene Fenster seine eigene Message-Queue oder gibt es eine für alle Fenster zusammen?
Beides :D Eine Queue für die GUI und die Eingaben/Nachrichten werden dann weiter an die Anwendungen verteilt.
-
Wie soll eine Anwenung für die GUI aussehen? Soll das so laufen wie bei Windows mit ner CreateWindow() Funktion? Und wenn man schon bei Messages sind: Wird die Queue für ein bestimmtes Fenster von einer Callback-Funktion wie bei Windows abgearbeitet oder wird es eine ähnliche/andere Lösung dafür geben.[/code]
-
Ich denke es wird so eine Art CreateWindows Funktion geben.
Die Callback-Funktion von Windows muss das Programm ja auch selber aufrufen daher denke ich werden wir es so machen das man die Nachrichten selber abruft und verarbeitet oder an eine Standartfunktion weiterreicht.
-
Okay. Und wie siehts mit Control-Erstellung aus? Wird das auch über Funktionen gemacht oder wird einfach eine Datei gelesen in der die Infos stehen? Ich wär hier für beides.
@Klassen:
Ich würde eine Klasse für Elemente oder sowas machen. Die hat nur Grundlegende Methoden/Eigenschaften, z.B. Position, oder eine Neu-Zeichnen-Methode. Und von dieser Klasse kann man dann eine Fensterklasse, eine Button-Klasse, usw. ableiten. Fenster kann man wieder unterteilen in Dialogboxen, Messageboxen, normalen Fenstern, MDI-Fenster, usw. Man kann so relativ leicht z.B. ein neues Control erstellen.
-
Ich würde eine Klasse für Elemente oder sowas machen. Die hat nur Grundlegende Methoden/Eigenschaften, z.B. Position, oder eine Neu-Zeichnen-Methode. Und von dieser Klasse kann man dann eine Fensterklasse, eine Button-Klasse, usw. ableiten. Fenster kann man wieder unterteilen in Dialogboxen, Messageboxen, normalen Fenstern, MDI-Fenster, usw. Man kann so relativ leicht z.B. ein neues Control erstellen.
Die Idee gefällt mir auch. Wie das erstellen von Controlls und das Verwalten dieser dann genau funktioniert weiß ich noch nicht aber es wird ohnehin noch etwas dauern bis wir daran arbeiten können.[/quote]
-
ich wuerde mich bei der API fuer die GUI auf jeden fall an .NET orientieren. klingt bloed, aber die lib ist sehr gut durchdacht und ist relativ einfach anzuwenden.
d.h. es wuerde eine haupt-basisklasse CControl geben, von der dann CWindow, CTextBox, CMenu, .. erben und ihre eigenen zeichenfunktionen und und und mitbringen.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformscontrolclasstopic.asp
[control-class]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformsformclasstopic.asp
[windows-form(also fensterl)-class]
lg, hannibal
-
.NET ist BÖSE ^^
Ich hab eine furchtbare Microsoft Phobie ^^
Egal ich finde wir sollten schon was mehr oder weniger eigenes machen.
-
natuerlich was eigenes, aber das prinzip, dass da dahintersteckt ist sehr sehr gut durchdacht und vereinfacht einem anwendungs-programmierer (auf gui-ebene) das leben um laengen! (man sehe sich bitte nur die C-WinAPI an..grausam(st)!)
lg, hannibal
-
Das kann nicht sein. .NET kann nicht von Microsoft sein. Microsoft macht sonst doch nur Scheiße.
-
Ich würde eine Klasse für Elemente oder sowas machen. Die hat nur Grundlegende Methoden/Eigenschaften, z.B. Position, oder eine Neu-Zeichnen-Methode. Und von dieser Klasse kann man dann eine Fensterklasse, eine Button-Klasse, usw. ableiten. Fenster kann man wieder unterteilen in Dialogboxen, Messageboxen, normalen Fenstern, MDI-Fenster, usw. Man kann so relativ leicht z.B. ein neues Control erstellen.
Sind diese Controls nicht eine ganz andere Ebene als grundlegende Grafikfunktionen und Eventverarbeitung usw., zumindest wenn man dem ursprünglichen Vorschlag folgen und etwas eher X-Server-mäßiges bauen will? Ich würde vorschlagen, das deutlich zu trennen, so daß das Toolkit mit den Widgets eine eigene, unabhängige Schicht ist, die auf den grundlegenden Funktionen aufsetzt.
PS: Ich hoffe, es nimmt mir niemand übel, daß ich mich gleich mit meinem ersten Post hier einmische... ;)
-
ach was :roll: ..microsoft ist kommerz; aber mit c# + .net hat man die moeglichkeit relativ einfach was feines unter windows (!) zu zaubern. sollte man was anderes wollen, kann man sich sowieso brausen gehn ^^
auf jeden fall wollte ich damit eine anregung geben, da ich (als microsoft-veraechter) wirklich der meinung bin, dass die GUI-lib in .net gut durchdacht ist.
ein weiterer vorteil gegenueber der herkoemlichen WinAPI sind die events; man braucht keine fette switch-anweisung, in der man lParam und wParam zerstueckelt um dann zu versuchen mit WM_BLAH irgendwelche events abzufangen - nein - stattdessen kann man fuer jedes event eine eigene prozedur anlegen (oder man legt keine an und verlaesst sich auf den standard-handler), um so individuell und punktgenau eingreifen kann (siehe interrupt-verwaltung; ist nichts anderes als sich in irq-leitungen einklinken)
lg, hannibal
(edit) taljeth:
die grundfunktionen muessen natuerlich vorhanden sein:
DrawPixel(), DrawLine(), DrawRectangle(), FillRectangle().. von mir aus auch DrawRadius() ..
die event-behandlung waere dann aehnlich der interrupt-behandlung auf lowlevel-ebene.
-
die grundfunktionen muessen natuerlich vorhanden sein:
DrawPixel(), DrawLine(), DrawRectangle(), FillRectangle().. von mir aus auch DrawRadius() ..
Jepp. Ich meinte nur, weil die Diskussion hier ziemlich durcheinander geht, obwohl Widget-Satz und die grundlegende Architektur doch eigentlich zwei völlig unterschiedliche Sachen sind - im Prinzip könnte man fast sagen, zwei verschiedene Projekte.
die event-behandlung waere dann aehnlich der interrupt-behandlung auf lowlevel-ebene.
Also auf deutsch gesagt, für die zu verarbeitenden Events registieren die Programme Callbacks bei der GUI (hm, was wäre ein passenderes Wort für diese untere Schicht?), die dann beim Auftreten eines entsprecheden Events aufgerufen werden, richtig? Halte ich für sinnvoll, jedenfalls besser als wenn jedes Programm seine eigene Event-Loop mitbringen muß.
-
die event-behandlung waere dann aehnlich der interrupt-behandlung auf lowlevel-ebene.
Also auf deutsch gesagt, für die zu verarbeitenden Events registieren die Programme Callbacks bei der GUI (hm, was wäre ein passenderes Wort für diese untere Schicht?), die dann beim Auftreten eines entsprecheden Events aufgerufen werden, richtig? Halte ich für sinnvoll, jedenfalls besser als wenn jedes Programm seine eigene Event-Loop mitbringen muß.
genau das. so kann man naemlich wirklich spezifisch auf events zugreifen und man kennt sich einfach im code aus ^^
-
Longhorn / .NET / was auch immer hat doch irgendeine neue Technologie, die die Controls mit ihren Parametern in einer XML-Datei speichert... das wär doch auch ne gute Idee, oder?
-
Wo hört bei euch der Kernel auf und wo fängt die GUI an?
Im Grossen und Ganzen wuerde ich es etwa so veranschlagen: Der Kernel liefert ein Treiberinterface, also im Prinzip nen paar Zeiger auf die Grafiktreiberfunktionen, welche unterstuetzt werden oder so ähnlich.
Die Aufgabe des Grafiktreibers sind grundlegend, also Grafikmodus setzen, Pixel, Linien, Dreiecke, Rechtecke, (Polygone) zeichnen, Teile verschieben, Bildschirmspeicher sichern. Halt nur die grundlegenden Sachen, welche man später mit speziellen Treibern optimieren könnte.
Auf diesen Treiber setzt dann ein Fenstermanager auf (wie unter Linux), welcher dann die Highlevelfunktionen wie Fenster zeichnen, Fensterklassen und Steuerelemente anbietet. Auf diese Funktionen greift dann die Anwendung zurueck.
Nun gibt es diverse Modelle, wie man das angehen kann.
Man kann Fenster als Fenster nehmen und Steuerelemente (wie Textfeld etc) von der Anwendung selbst machen lassen. Das hätte nur den Nachteil, dass jede Anwendung das Rad neu erfinden muesste und das OS keine xfach getesteten Funktionen zur Verfuegung stellt. Das wäre unelegant.
Man könnte auch die Steuerelemente vom OS als "Goodies" dazugeben, sei es festkompiliert oder extern nachgeladen (Bibliotheken). Benutzt muss es ja nicht werden, wer sein SuperDuperTextfeld mit Rechtschreibpruefung haben will, soll es implementieren :-)
Aber nun muss man sich ueberlegen, wie weit die Integration der Steuerelemente funktionieren soll. Wenn ein Ereignis auftritt (und es sind viele, zB MouseMove), soll das Ereignis an die Applikation, an das Fenster oder an das Steuerelement gesendet werden? Dies beeinflusst das Programmieren der Anwendung nicht unerheblich.
Sendet man es an die Anwendung, so hat diese alle grafischen Funktionen an einer Stelle, muss sich jedoch immer darum kuemmern, wer nun eigentlich das Ereignis ausgelöst hat (man kann ja den Index eines Steuerelements dazugeben, dann wird das einfacher).
Sendet man es an das Fenster, so werden die Fenster fuer den Programmierer getrennt, was Vor- und Nachteile mit sich fuehrt, da man bei gewissen Sachen halt auf ein Fenster beschränkt ist.
Schliesslich kann man das Ereignis auch direkt ans Steuerelement senden, was man als Programmierer wieder anderweitig handhaben muss.
Ich persönlich wuerde Messages an das Hauptfenster senden, denke ich. Sollte ich nen Gedankenfehler drin haben... sagt's einfach.
Nun muss man ueberlegen, wie man Fenster ueberhaupt intern darstellt. Gibt es nur "das" Fenster, oder verschiedene Typen wie z.B. Dialog etc. Diese Typen könnte man dann anpassen und damit evtl. sogar eine Optimierung erzeugen - ein Dialog muss keine Maximierenfunktion besitzen, wenn sie eh ausgeblendet wird. Man sollte auch ein grobes "nichts"-Fenster haben, womit sich die Anwendung dann komplett selbst designen kann.
Werden Steuerelemente von Fenstern abgeleitet? Was bringt das fuer Vor- und Nachteile? Vorteile sind, dass man diverse Funktionen nicht extra einbinden muss, diese demgegenueber aber auch nicht optimiert sind auf den Zweck. Die Programmierung wird einfacher. Nachteiligerweise wird das Steuerelement grösser im RAM und etwas langsamer.
Werden Steuerelemente einfach auf das Formular "projiziert" oder gezeichnet? Also, ist es vom Formular getrennt oder mit diesem verschmolzen?
Ersteres macht das dynamische Erstellen (bzw. wieder Entfernen) ziemlich einfach und schnell und verkompliziert die Programmierung; letzteres ist von der GUI einfacher zu handhaben.
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. Auch könnte das Hauptfenster dann beim Windowmanager fuer jedes Steuerelement eine(!) Prozedur angeben. Das ist nicht unbedingt effektiv (wegen der ständigen Zerstueckelung der Parameter, welches Ereignis das nun war), aber erleichtert das Programmieren des Fenstermanagers ungemein. Man stelle sich vor, eine Anwendung schreibt drei Dutzend Funktionen fuer diverse Ereignisse und der Windowmanager ruft diese dann auf. Wäre fuer mich Schwachsinn, da ist eine Verteilerfunktion im Fenster dann schon besser.
Ich hab das jetzt mal Rueckwärts von VB gesehen. Teilweise wurde das eine oder andere sicher schon gesagt, auch habe ich vieles zwischendurch vergessen, was ich noch schreiben wollte :( und auch vieles vereinfacht dargestellt.
Ein Ziel ist zwar wichtig, aber der Weg sollte bei diesem Betriebssystem überhaupt das Ziel sein. Denn es war als LernOS geplant, nicht als Konkurrenz zu irgendetwas.
Ach ja und noch etwas in eigener Sache... es wäre schön, wenn die Grafische Oberfläche schnell und sparsam wäre (aus Sicht des Rechners), also so schnell wie möglich programmiert (nicht unbedingt hochoptimiert). Ich weiss zwar nicht, wie die Anforderungen liegen, aber ein OS mit Textverarbeitung, welches auf nem 486er in 15sec komplett geladen ist (auf nem P4 dementsprechend schneller ;) ) wuerde so ziemlich allem den Rang ablaufen, was ich hier so habe. Ein ineffizientes OS wie die neueren Windosse (wo man halt bei weniger Megahertzen bei jedem Klick ne halbe Ewigkeit warten muss) möchte ich nicht haben.
Soweit erstmal ein paar (hoffentlich gute) Anregungen, wie man die GUI designen könnte.
Svenska
-
Im Grossen und Ganzen wuerde ich es etwa so veranschlagen: Der Kernel liefert ein Treiberinterface [...].
Die Aufgabe des Grafiktreibers sind grundlegend, also Grafikmodus setzen, Pixel, Linien, Dreiecke, Rechtecke, (Polygone) zeichnen, Teile verschieben, Bildschirmspeicher sichern.
Klingt soweit sinnvoll.
Auf diesen Treiber setzt dann ein Fenstermanager auf (wie unter Linux), welcher dann die Highlevelfunktionen wie Fenster zeichnen, Fensterklassen und Steuerelemente anbietet. Auf diese Funktionen greift dann die Anwendung zurueck.
Wenn du dich an Unix/Linux orientierst, hast du dabei noch eine wichtige Schicht vergessen: Den X-Server. Bei dir müßte der Windowmanager z.B. auch das Eventhandling oder die Darstellung von Schrift mit übernehmen. Spätestens wenn man sich nicht auf einen Windowmanager beschränken will, ist das keine gute Idee mehr.
Ich glaube auch nicht, daß die Steuerelemente vom Windowmanager angeboten werden sollten - schon der Name sagt ja, daß sich der WM um Fenster kümmert.
Man kann Fenster als Fenster nehmen und Steuerelemente (wie Textfeld etc) von der Anwendung selbst machen lassen. Das hätte nur den Nachteil, dass jede Anwendung das Rad neu erfinden muesste und das OS keine xfach getesteten Funktionen zur Verfuegung stellt. Das wäre unelegant.
Es spricht ja nichts dagegen, daß die Anwendungen eine einheitliche Bibliothek einbinden. Für furchtbar unelegant halte ich diesen "light-weight"-Ansatz nicht.
Im übrigen, QT macht genau sowas. Und nachdem KDE, das auf QT aufbaut, der führende Desktop unter Linux ist, kann es so furchtbar schlecht nicht sein.
Man könnte auch die Steuerelemente vom OS als "Goodies" dazugeben, sei es festkompiliert oder extern nachgeladen (Bibliotheken).
Ok, auf das mit den Bibliotheken wollte ich wohl hinaus... ;)
Aber nun muss man sich ueberlegen, wie weit die Integration der Steuerelemente funktionieren soll. Wenn ein Ereignis auftritt (und es sind viele, zB MouseMove), soll das Ereignis an die Applikation, an das Fenster oder an das Steuerelement gesendet werden? Dies beeinflusst das Programmieren der Anwendung nicht unerheblich.
Ein klassischer Windowmanager verwaltet Fenster, das wäre also die naheliegendste Sache. Wobei die anderen Widgets natürlich intern auch als Unterfenster verwaltet werden können (dann wären wir bei schwergewichtigen Toolkits), dann würden die Events direkt an das Steuerelement geliefert.
Wo übrigens die Nachteile für den Programmierer sein sollen, wenn man ans Fenster oder das Widget liefert, leuchtet mir grad nicht richtig ein. Nach oben durchreichen sollte doch kein Problem sein, wenn ich die Sache auf einer höheren Ebene bearbeiten will?
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.
Nun muss man ueberlegen, wie man Fenster ueberhaupt intern darstellt. Gibt es nur "das" Fenster, oder verschiedene Typen wie z.B. Dialog etc.
Ich denke, man sollte das Konzept Fenster von der grafischen Darstellung eines konkreten Fensters trennen. Ich schlage folgende grobe Definition vor: Ein Fenster ist ein vom WM verwaltetes Objekt, muß also optisch überhaupt nicht an ein Fenster erinnern, sondern kann auch ein Button, Icon oder sonstwas sein. Die konkreten Widgets, die dann als Fenster beim WM registriert werden, sind Sache der Anwendung (ja, natürlich auch hier wieder Bibliotheken).
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. Als Anwendungsprogrammierer würde ich also am liebsten sowas schreiben (ich weiß, falsche Sprache ;)):
button.onClick := @handlerFunktion;
Man stelle sich vor, eine Anwendung schreibt drei Dutzend Funktionen fuer diverse Ereignisse und der Windowmanager ruft diese dann auf. Wäre fuer mich Schwachsinn, da ist eine Verteilerfunktion im Fenster dann schon besser.
Denke ich nicht. Sowas braucht jede Anwendung in etwa gleicher Form, also kann man es gleich in eine andere Schicht rausziehen.
Ich hoffe, daß ich nicht zu einseitig vom X-Server-Konzept ausgegangen bin, aber ihr könnt mich ja verbessern. ;)[/code]
-
Auf diesen Treiber setzt dann ein Fenstermanager auf (wie unter Linux), welcher dann die Highlevelfunktionen wie Fenster zeichnen, Fensterklassen und Steuerelemente anbietet. Auf diese Funktionen greift dann die Anwendung zurueck.
Wenn du dich an Unix/Linux orientierst, hast du dabei noch eine wichtige Schicht vergessen: Den X-Server. Bei dir müßte der Windowmanager z.B. auch das Eventhandling oder die Darstellung von Schrift mit übernehmen. Spätestens wenn man sich nicht auf einen Windowmanager beschränken will, ist das keine gute Idee mehr.
Gut, das habe ich vergessen. Aber das wäre wieder eine Schicht dazwischen, welche nicht unbedingt notwendig ist. Wenn das OS jetzt eine Konkurrenz zu Linux/Unix werden soll, gut, dann ist mein Konzept etwas zu einfach bzw. nicht komplex genug.
Aber das Ziel ist der Weg - oder sollte es von der Idee sein - und da wuerde ich nicht unbedingt vorschlagen, alles extrem getrennt zu machen.
Mir wären - der Uebersicht halber - Mikrokernel => Treiber => WM lieber. Damit hätte man dann keine Scherereien über xy verschiedene Instanzen und da wir ja bei weitem noch nicht soweit sind... nun gut, Designfraegn sind am Anfang zu klären.
Es hängt davon ab, was dieses OS mal werden soll. Ein Linux-Klon ohne Linux? Ein OS wie jedes andere? Ich glaube, damit wird es weniger etwas. Ein OS wie MenuetOS wird bekannt, weil es 100%ASM auf 1.44MB ist. ReactOS, weil es Windows-kompatibel ist. Unser OS, weil der Source das allgemeine Verständnis fuer "wie" ein OS aufgebaut ist, am Beispiel zeigt? Oder soll es doch nur ein OS wie die tausend anderen werden?
Das nächste OS, was ich schreibe (mein erstes *g*) wird auf nen 286er zugeschnitten sein; das wäre dann das zweite, meines Wissens (nach OS/2 1.x), welches diesen dann ausreizt.
Aber - und darauf kommt es an - ein OS muss ein Ziel haben. Ein Allround-OS wie Windows oder Linux braucht hunderte, wenn nicht tausende Programmierer. nicht die paar 10 Leute, die aktiv an LOST arbeiten.
Man kann Fenster als Fenster nehmen und Steuerelemente (wie Textfeld etc) von der Anwendung selbst machen lassen. Das hätte nur den Nachteil, dass jede Anwendung das Rad neu erfinden muesste und das OS keine xfach getesteten Funktionen zur Verfuegung stellt. Das wäre unelegant.
Es spricht ja nichts dagegen, daß die Anwendungen eine einheitliche Bibliothek einbinden. Für furchtbar unelegant halte ich diesen "light-weight"-Ansatz nicht.
Ich meinte damit, dass es keine Steuerelemente gibt, dass jede Anwendung ihre eigenen Teile auf ein - vom WM gestelltes - Hauptfenster (Frame) raufmalt.
Den Rest beantworte ich sÃ¥äter, da ich wieder zum Unterricht muss.
Svenska
-
Wenn du dich an Unix/Linux orientierst, hast du dabei noch eine wichtige Schicht vergessen: Den X-Server. Bei dir müßte der Windowmanager z.B. auch das Eventhandling oder die Darstellung von Schrift mit übernehmen. Spätestens wenn man sich nicht auf einen Windowmanager beschränken will, ist das keine gute Idee mehr.
Gut, das habe ich vergessen. Aber das wäre wieder eine Schicht dazwischen, welche nicht unbedingt notwendig ist. Wenn das OS jetzt eine Konkurrenz zu Linux/Unix werden soll, gut, dann ist mein Konzept etwas zu einfach bzw. nicht komplex genug.
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.
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.
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.
-
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 :) 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? ;) ;)
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
-
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.
Eine solche Aussage in einem Projekt, das einen Microkernel bauen will, finde ich doch recht erstaunlich. ;)
Außerdem habe ich ja nichts dazu gesagt, wie weit die Trennung gehen soll. Aber modulare Programmierung halte ich doch für einen gewissen Fortschritt gegenüber der Steinzeitinformatik. Und saubere Schnittstellen haben noch niemandem geschadet. Ob man daraus dann eigene Bibliotheken baut oder nicht, das kann man sich noch überlegen. Es handelt sich auf jeden Fall um unterschiedliche Sachen.
Später (viiieeelll später) könnte man das vielleicht noch aufteilen, aber ich bin wie gesagt kein Befuerworter.
Eher nein. Was einmal steht, wird nicht so leicht wieder umgeworfen, auch wenn es noch so ungeschickt ist.
Ja, aber das wuerde die GUI wieder arg vereinfachen :)
Wollen wir etwa immer das einfachstmögliche, egal welche Schwierigkeiten es hinterher bei der Anwendung mit sich bringt?
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.
Zumindest von Programmen erweiterbar muß die Sache schon sein. Den Programmen eine Auswahl von genau 27 Widgets hinzuwerfen und sie für immer darauf zu beschränken, bringt nichts. Daher würde ich die Standard-Widgets auch lieber auslagern, so daß sie relativ isoliert sind und sich halbwegs einfach ersetzen lassen.
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?
Wir sind nicht allein auf der Welt. Ein gewisser Grad an Kompatibilität sollte imho schon sein.
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? ;) ;)
Ok, du baust mir dann die ganzen Tools nach, die man sonst halbwegs einfach kriegen würde, ja? ;)
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.
Einspruch. Den Anwendungen sollte es einfacher gemacht werden: Es gibt genau einen GUI-Server, aber viele Anwendungen. Wenn man es in der GUI einmal richtig macht, hat nicht jede Anwendung die "Chance", es auf ihre eigene Weise falsch zu machen - außer wenn sie es wirklich will...
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...
Sorry, aber den Zusammenhang dieser beiden Aussagen kriege ich irgendwie nicht sinnvoll interpretiert...
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...
Wenn du ein Event nicht brauchst, registrierst du halt gar keinen Eventhandler...
-
Da LOST auf eine GUI aufsetzt und nicht auf eine Konsole, ist das einer der Hauptpunkte, die dafuer sprechen.
Wusste ich garnicht ?
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...
Bin auch für's nach unten weiterreichen.
Soll die GUI einfach sein oder sollen die Anwendungen einfach sein?
Bin auch für eine eher einfache GUI.
Für Dinge wie CALLBACK-Funktionen etc. müsste der Kernel zuerst die möglichkeiten dazu anbieten und wir müssten wissen wie wir die dann genau nutzen können...
-
Für Dinge wie CALLBACK-Funktionen etc. müsste der Kernel zuerst die möglichkeiten dazu anbieten und wir müssten wissen wie wir die dann genau nutzen können...
Naja, irgendeine Kommunikation brauchen wir auf jeden Fall. Sind simple Callbacks da nicht eher eine einfache Alternative, wenn ich mir so anschaue, was Qt oder Swing veranstalten?
-
Möglichkeiten wären wohl ohnehin nur Callbacks und Syscalls mehr kenne ich nicht :wink:
Es sei den ihr wollt UNIX-Sockets implementieren ^^
-
Wie wäre es denn mit Pipes zu Kommunikation?
Das wäre meiner Meinung nach neben Messagequeues die einfachste Methode, ausserdem sind sie flexibler als Callbacks / Messagequeues
-
An der Stelle sollte man vielleicht einfach mal auf das Kernel-Team warten, was man sich dort in Sachen Kommunikation einfallen läßt. ;)
-
OK taljeth. Ich gebe mich geschlagen, da wir verschiedene Ziele verfolgen.
In dem Moment liegen die Punkte natuerlich wieder anders; ich wollte es
so einfach wie möglich machen, dass man also auch mit weniger
Kenntnissen noch im Code durchsehen kann und auch sonst weiss, wie
ein OS aufgebaut ist. Du hingegen möchtest etwas produktives
entwickeln, wo der Lernzweck im Hintergrund steht.
In dem Moment ist dein Ansatz um Weiten besser, wenn auch
komplizierter.
Svenska
-
Ihr meint, dass es pro Event eine Prozedur geben muss oder sehe ich es falsch? Dann gibt es verdammt viele Prozeduren, die man anmelden muss, wenn man ein von der Grafik her gutes Proggi machen möchte (Move_Mouse,MouseKlick usw....) Wäre es nicht sinnvoller dann die Events in Gruppen zu unterteilen und jeder Gruppe z.B. eine Funktion zuzuweisen(Keyboard, Mouse, Joystick, Timer...usw). Denn wenn ich eine mini-dialogbasierte Anwendung progge, brauche ich ja keine Tastatur. Wenn man die Events mit keiner Funktion belegt, wird die default-Funktion des GUI ausgeführt.
Kurze Frage zu Ressourcen, wollt ihr die in die Executable miteinbinden (z.B. Bitmaps) oder wollt ihr die Ressourcen aus extra Quellen laden? Da sollte man sich über executable-Format Gedanken machen.
-
Ihr meint, dass es pro Event eine Prozedur geben muss oder sehe ich es falsch?
Wenn ich ein Ereignis verarbeiten will, muß ich dafür eine Prozedur schreiben, ja. Aber alles andere wäre sowieso kein guter Programmierstil.
Wäre es nicht sinnvoller dann die Events in Gruppen zu unterteilen und jeder Gruppe z.B. eine Funktion zuzuweisen(Keyboard, Mouse, Joystick, Timer...usw).
Darf ich raten, wie dein Mouse-Eventhandler dann aussieht? Also als erstes kommt garantiert ein Switch, das unterscheidet, ob es jetzt ein MouseClick, MouseMove oder sonstwas war. Wieso also nicht gleich trennen?
Denn wenn ich eine mini-dialogbasierte Anwendung progge, brauche ich ja keine Tastatur. Wenn man die Events mit keiner Funktion belegt, wird die default-Funktion des GUI ausgeführt.
Es zwingt dich ja niemand, Handler für Tastaturereignisse zu registrieren. Wenn nichts registriert ist, wird eben auch nichts ausgeführt.
Kurze Frage zu Ressourcen, wollt ihr die in die Executable miteinbinden (z.B. Bitmaps) oder wollt ihr die Ressourcen aus extra Quellen laden? Da sollte man sich über executable-Format Gedanken machen.
Für das Executable-Format ist eher der Kernel verantwortlich.