Nachrichten

2741

tyndur / GUI-Team

« am: 21. May 2005, 10:27 »

Kommt drauf an, was man jetzt unter GUI-Server versteht: Wenn das jetzt das Ding sein soll, wo das gesamte Programm mitsamt Windowmanager usw. drin ist, würde ich eher nein sagen.

Ich glaube, wir sollte langsam mal ein paar Begriffe klären.

2742

tyndur / GUI-Design-Vorschläge

« am: 20. May 2005, 19:24 »

War nicht unbedingt ernst gemein, erst recht nicht mit diesem Farbschema... Aber das hat für mich irgendwie echten Nostalgiewert, bin schon lang nicht mehr an so einer Kiste gesessen. Und ganz ehrlich: Ich finde, die Buttons und Dialogboxen sehen wirklich gar nicht so schlecht aus. Ich liebe 2D.

Da sieht man übrigens noch ein paar Elemente mehr: http://www.winhistory.de/more/pics/WIN2112.gif

2743

tyndur / GUI-Design-Vorschläge

« am: 20. May 2005, 16:56 »

Also ich bin ja definitiv für einen Windows 2.0-Look, das hat wenigstens Stil.

2744

tyndur / GUI: Technische umsetzung

« am: 20. May 2005, 15:48 »

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

2745

tyndur / GUI: Technische umsetzung

« am: 20. May 2005, 15:28 »

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?

2746

tyndur / GUI: Technische umsetzung

« am: 20. May 2005, 15:06 »

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

2747

tyndur / GUI: Technische umsetzung

« am: 20. May 2005, 12:31 »

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.

2748

tyndur / GUI: Technische umsetzung

« am: 20. May 2005, 11:46 »

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]

2749

tyndur / GUI-Team

« am: 20. May 2005, 00:23 »

Soweit es meine Zeit zuläßt, würde ich auch gern beim (Code-)Design mitmischen.  

2750

tyndur / GUI: Technische umsetzung

« am: 19. May 2005, 23:33 »

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

2751

tyndur / GUI: Technische umsetzung

« am: 19. May 2005, 23:10 »

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