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
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken
Thema: GUI: Technische umsetzung (Gelesen 23273 mal)