Thema: GUI: Technische umsetzung

[kevin]

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]

[Svenska]

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

[kevin]

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.

[Svenska]

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

[kevin]

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...

[Golum]

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...

[kevin]

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?

[Golum]

Möglichkeiten wären wohl ohnehin nur Callbacks und Syscalls mehr kenne ich nicht  
Es sei den ihr wollt UNIX-Sockets implementieren ^^

[SSJ7Gohan]

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

[kevin]

An der Stelle sollte man vielleicht einfach mal auf das Kernel-Team warten, was man sich dort in Sachen Kommunikation einfallen läßt.

[Svenska]

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

[Netmaster]

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.

[kevin]

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.