Hallo,

falls ihr noch ein bisschen Inspiration für eure Arbeit sucht, könnt ihr euch ja mal Awt oder Swing von Java anschauen.

Diese GUIs sind zwar von der Geschwindigkeit her nicht sehr optimal, dafür aber äusserst flexibel und konzeptional ziemlich sauber

Viele Grüße
dj3hut1

@dj3hut1:
ja, werden wir machen. Ich habe allerdings einmal mit der Delphi-VCL angefangen, sihe mein nächster beitrag, den ich in Kürze reinstelle.

i0n0s:
klingt gschmackig: "OnHover", zergeht einem richtig auf der Zunge. Allerdings muss ich da noch nachdenken, wie mans gut einbaut.
Traude

Ein Seitenblick auf die VCL (Virtual Component Library) von Delphi
(Leider noch ein Monsterbeitrag)

Hallo,
Im vorigen Beitrag habe ich meinen Vorschlag für ein Grundkonzept der GUI vorgestellt. Heute möchte ich ein paar Zitate zum Besten geben. Die Quelle dafür ist ein ziemlich umfangreiches Buch: Delphi 5 von Elmar Warken, Verlag Addison-Wesley, Jahr der Ausgabe: 2000.

Ich wollte damit auch die Frage näher beleuchten, wer denn die GUI-Objekte erzeugen soll. Denn Objekte können sich glaube ich nicht selbst erzeugen. Sie könnten sich vielleicht selbst freigeben, denn sie können theoretisch ihre Methode Free selbst aufrufen. Diese Vorgangsweise würde ich allerdings nicht empfehlen. Denn: Ich beachte beim Programmieren immer bestimmte Benimm-Dich Regeln. Eine dieser Regeln lautet: Wer ein Objekt erzeugt ist für es verantwortlich, auch dafür, dass es in einer kontrollierten Art und Weise freigegeben wird. Natürlich kann es spezielle Fälle geben, wo man von dieser Regel abweicht. Dann muss es für dieses Abweichen aber einen triftigen Grund geben und man handelt sich jede Menge zusätzlichen (schlecht lesbaren) Code ein.

Im meinem Konzept kann der Programmierer mit der Methode "AddGUItem" die Erzeugung eines GUI-Element in Gang setzen und sich einen Zeiger auf das GUI-Element holen. Aber er wird dadurch nicht Eigentümer des GUIItems. Das bedeutet, er muss sich nicht um die Freigabe kümmern, kann aber die Public und Published Eigenschaften des Elements manipulieren. Das Aufrufen des TGUIElement.Free durch das aufrufende Programm muss daher unterbunden werden. Ich könnte mir aber vorstellen, dass das Freigeben analog zur Methode "AddGUItem" mit einer Methode "DeleteGUIItem" geschieht. Irgendjemand muss schließlich das Parent davon informieren, dass eines seiner Kindelemente abhanden gekommen ist. Oder würdet ihr wollen, dass Euch jemand ein einfach so ein Kindlein stiehlt, oder auch, dass Euch jemand einen Wechselbalg unterschiebt?

In obig zitiertem Buch heißt es im Kapitel "3.2.2 Die Fensterhierarchie" (es geht um die Delphi-VCL):



In der VCL hat ein Fenster alle seine Komponenten in einer Liste und offenbar ZUSÄTZLICH einen Baum installiert. Warum, weiß ich nicht. Vielleicht kanns mir jemand verraten. Oder vielleicht hängt es damit zusammen, dass z.B. TPanel einen eigenen Rendering Context haben kann?


Und im gleich anschließenden Kapitel "3.2.2 Die oberste Komponente: TApplication" heisst es:



Für mich heißt das: TApplication entspricht irgendwie meinem GUI-Manager.

Unterschiede:
1) Der GUI-Manager hat folgende Hierarchie: TObject -> TGUIItem -> TGUIManager und ist somit kein TComponent.
2) Der GUI-Manager muss von der aufrufenden Anwendung erzeugt und freigegeben werden, TApplication braucht das nicht.
3) TApplication kümmert sich um die ganze Anwendung, TGUIManager stellte in meinem vorigen Projekt bloß ein Meldungsfenster zur Verfügung, dass der Anwender immer benutzen kann, vorausgesetzt, es kann ÜBERHAUPT etwas gezeichnet werden (vielleicht ist jetzt klarer, warum ich immer auf dem Thema "Ich-möchte-wissen-ob-die-Grafikausgabe-funktioniert" herumreite).

Wenn ich mir die obigen Erläuterungen etwas "eindeutsche", siehts für mich so aus: TApplication betreut das ganze aufrufende Programm. Man könnte auch sagen es reißt die Macht an sich.

Das dürfte unseren Vorgaben nicht entsprechen. Natürlich ist es wünschenswert, wenn sich der GUI-Manager um sein Zeug alleine kümmert, wenn er mal erzeugt ist. Aber er soll nicht gleich das ganze Programm übernehmen. Als Programmierer würde ich mir wünschen, dass ich ihn in Betrieb nehmen, aber auch zu Teufel schicken kann, wenn's mir in den Kram passt, und zwar einfach mit GUIManager.Free. Da aber Delphi das so gemacht hat wird wohl ein Grund dafür vorhanden sein. Ich tippe mal: es soll dem Programmierer möglichst viel Arbeit abgenommen werden? Wenn das so stimmt, dann sieht es mir aber auch ein wenig nach Entmündigung aus.

Aber eins scheint mir sicher: dieses mein Konzept eines GUI-Managers kann im Augenblick nur EINEN Rendering Kontext verwalten. Für einen zweiten Rendering Context müsste man auch einen zweiten GUI-Manager erzeugen.

Wenns jemanden interessiert, MEIN Baumkonzept stammt nicht aus der VCL. Ich habe das Baumkonzept erst vor kurzem näher kennen gelernt, und zwar beim Erstellen einer Bone-Struktur für ein 3d-Objekt. Da habe ich (mit offenem Mund) gesehen, was Bäume imstande sind. Und die GUI schreit geradezu nach einer Baumstruktur.

So und jetzt warte ich mal, was Ihr dazu sagt, weil ich mir denke, dass man das zunächst einmal ein wenig verdauen muss.
Traude

Ich würde an dieser Stelle sogar noch einen Schritt weitergehen und die Methoden im Basisobjekt als abstract deklarieren. Dadurch vermeidet man, dass eine Überschreibung vergessen wurde, indem dann bei der Instanzierung gewarnt wird, dass eine Instanz mit abstrakten Methoden erzeugt wird.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Es sind in der Tat zwei Bäume:
Der erste (Components) regelt die Besitzerschaft. Hier wird die Owner-Hierarchie abgebildet. Sobald ein Component einen Owner zugewiesen bekommt, trägt es sich in dessen Components-Liste ein. Damit regelt man sozusagen die Freigabe-Hierarchie.
Der zweite(Controls) regelt die Elternschaft. Hier passiert im Prizip das Gleiche bei der Zuweisung eines Parents. Allerdings ist Controls 'mächtiger' als Components, da hier Sictbarkeit, Parent-Eigenschaften (Font) und Windows-Nachrichten weitergericht weren.

In einer Standart-DFM ist z.B.: immer das Formular der Owner, aber z.B:: ein Panel der Parent. Das eine regelst also die Besitzerschaft, das andere die Fensterhierarchie.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

@Sidorion schrieb:

Ja , Du hast recht . Ich tus nur nicht gern. Aber ich gebe gerne zu, dass ich keine Argumente dagegen anführen kann.

Bezüglich der Info über die VCL: Danke, hilft mir sehr.
Traude

Zur Freigabe:
Ich wäre noch dafür, dass die Freigabe des Root-Elementes ausreicht.

Zu dem AddGUIItem hatte ich ja schon vorher was geschrieben was noch immer aktuell ist...
An der Stelle fühle ich mich etwas überlesen.

Das mit der VCL finde ich aktuell auch komisch, könnte natürlich mit dem Renderkontext sein, aber die Komponenten in dem Panel werden dann denoch gezeichnet. Hier wäre es wirklich nett wenn jemand Licht ins Dunkle bringen könnte.

Dann zu den Unterschieden zwischen GUI-Manger und TApplication:
Zu 2.: TApplication wird anscheinend in der Initialization der Unit forms.pas erstellt und in der Finalization freigegeben. Bei uns wird es erst zu späteren Zeitpunkten erstellt, da es nur eine GUI ist, die sich nicht um die Fenstererstellung und solchen Kram kümmern sollte. (-> 3.)

Und Borland hat es so gemacht, weil es einen Programmierer viel Arbeit erspart. Wir hatten/haben ein Tutorial zur Erstellung eines Fensters mit der Winapi und das ist rech hässlich. Daher wird früher oder später jeder Programmierer sich ein Framework schreiben, unter anderem die Delphientwickler. Und genau dieses haben sie dann der Öffentlichkeit "geschenkt", damit Delphi auch für Windowsdesigner recht einfach zu benutzen ist.


Das stimmt und ist ein guter Punkt, den an der Stelle müssen wir uns gedanken machen, wie wir es umgestalten könnten, dass es auch mit mehreren Rendercontexten klappt.


Die Baumstruktur bietet sich dafür an, wieso sollten wir sie nicht nehmen?

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Die VCL ist und bleibt nur eine Kappselung der Window API. An einigen vielen Stellen übernimmt sie noch selber etwas aber man könnte auch komplett auf sie verzichten. Und die Strukturen der VCL sind nur zu dessen eigene Verwaltung wichtig. Sobald du Parent aufrufst wird WINDOWS mitgeteilt, dass dieses Fenster ein Unterfenster eines anderen ist. Und WINDOWS sorgt dann dafür, dass dieses gezeichnet wird. Sozusagen hast du sowohl in der VCL einen Baum und im Windows Fensterhandler auch noch einmal.

zu VCL: Das liegt in der Klassenhierarchie begründet: Die Klasse TComponent ist Vorfahr für alle Klassen, die einen Owner haben (Freigabe). Die Klasse TWinControl ist Vorfahr für alle Klassen, die einen Parent haben (Anzeigeelemente). Da nun TWinControl Nachfahre von TComponent ist, hat es beide Listen.

zu mehrere RC: sowas hatte ich in meiner Diplomarbeit. Da gab es eine Klasse TGraphicContainer, der weitere Container in sich halten konnte. So eine art 'Parent' geschichte, da jeder GraphicContainer eine Matrix bezogen auf seinen 'Parent' hatte. Dadurch konnte ich mit relativen Koordinaten arbeiten.
Von TGraphicContainer wurden dann zwei Klassen abgeleitet: TGraphicWorld und TGraphichControl.
TGraphicWorld wäre sozusagen dann der GUI-Manager und TGraphicControl ein Panel/Button/Edit usw.
Die Welt war immer Root und kannte die Gesamtabmaße aller Conttrols und sorgte fürs Zeichnen, allerdings völlig ohne Renderkontext. D.h.: die Controls haben einfach die gl-Funktionne gerufen.
Zusätzlich gab es TOpenGL-Panel, die jeder für sich einen eigenen RC, eine 'Kameraposition' und einen Bezug zur TGraphicWorld hatten. Diese waren sozusagen die 'Fenster', durch die man auf die Welt geschaut hat. Wenn jetzt die Welt derendert wurde, wurde für jedes TOpenGLPanel die Render-Methode gerufen, die den eigenen RC aktiviert, die Kameraposition (gluLookAt) festgelegt und die Welt gerendert hat.

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Uff soviel Text und sowenig Zeit Den letzten Monsterbeitrag muss ich noch zu ende lesen, den Rest hab ich soweit.

dj3hut1s Vorschlag mit dem Swing GUI solltet ihr wirklich mal in Betracht ziehen. Es ist an einigen Stellen zwar ebenso grausam wie andere GUIs, aber im großen und ganzen doch recht ausgereift...

Ok, nun zum eigentlichen Teil.

@Baumstruktur: Eine reine Baumstruktur halte ich für unnötig. Ich würde die proklamierte Variante von Parent -> Child (Parent) -> Child bevorzugen. Das also jedes Element für sich und seine Firstlevel Kindelemente primär zuständig ist. Ereignisse wie das Widget sichtbar und nicht sichtbar zu setzen werden zwar an die Unterlemente weitergereicht, können aber durch den Einsatz von zb. Listenern in den jeweiligen Unterlementen abgefangen werden. Das würde es zb. ermöglichen ein Fenster das gerade ein Popup anzeigt auszublenden, aber das Popup würde sichtbar bleiben.

Auch finde ich die Baumstruktur für die Ereignisverwaltung wenig sinnvoll. Warum? Weil bei einem größeren GUI der Baum größer wird und die Suchzeit somit länger braucht. Auch ist es schwieriger und kostenintensiver Ereignisse zu verschicken die sich auf einen ganz andern Ast im Baum beziehen, da der Baum dann neu durchlaufen werden müsste.

Hier ist der Ansatz von Swing und vielen anderen GUIs über einen Ereignismanager sehr praktisch. Dahinter verbirgt sich nichts anderes als ein Manager der in seinem eigenen Thread bzw. einem Nebenthread der GUI zum zeichnen läuft und auf alle Ereignisse aufpasst, ist ähnlich wie bei Windows, und die Referenz zum jeweiligen Objekt gespeichert hat. Diese hat er selbstverständlich nur, wenn das Objekt auch bei ihm registriert wurde. Dadurch ist der Overhead den wir beim Baum hätten der durch das traversieren selbigens automatisch entsteht beiseite geschoben.

@Maustasten: Mehr als LM, RM, MM, MR_UP, MR_DOWN sind für eine GUI denke ich nicht relevant. Was will man mit einer vierten Taste (Daumentaste) bei einem GUI? Seh ich wenig verwendung für. Die anderen sollten drin sein, da sie von einer Handelsüblichen 3 Tasten-Maus abgedeckt werden.

@Diagramme: Kann hier jemand UML 2? Sonst würd ich mich dafür mit zur Verfügung stellen und anhand des bestehenden Konzeptes zumindest mal einen Vorschlag für eine Klassenstruktur zu machen.

@OOP/Free Pascal: Ich weiß zwar nicht in wie weit euer FreePascal OOP unterstützt, aber generell sollte man OOP konsequent durchziehen wenn man es nutzen will. Dazu fällt mir zb. noch ein das geklärt werden muss wie ein GUI Element und dessen grafische Ausgabe behandelt werden. Ich denke eine Art des MVC (Model View Controller) Pattern wäre hier nicht verkehrt. Dieses kann man bei Bedarf sehr gut mit anderen Pattern mixen und zb. den M und C Part als ein Element behandeln, sodass nur noch die View als seperates Element vorliegt. Dies würde zusätzlich die Möglichkeiten zur Verwendung von Styles vereinfachen.

@Kein Debug bei Listen: Wieso kann man in Delphi zur Laufzeit nicht sehen was in einer Liste steht? Das muss doch gehen!? o_O

Mehr folgt später, meine Mittagspause ist zu ende.

_________________
(\__/)
(='.'=)
(")_(")

Du lieber Himmel, mit soviel Echo hatte ich gar nicht gerechnet.
Otto Waalkes sagte einmal: "Diese Begeisterung sollte man sexuell ausnutzen - aber ich schaff' sie nicht alle".
(Bitte verzeiht einer alten Dame ihre geschmacklosen Witze - Hoffentlich ist kein Zensor unterwegs - duck und weg).


Zuerst kommt aber I0n0s dran, hab offensichtlich was übersehen:

I0n0s schrieb:


Ist es das, was Du meinst:

I0n0s schrieb:


Betrifft Deinen Fall Nr.2: Wenn das GUI-Item public/published ist, kommt z.B. ein Array-Property in Frage. Könnte ich mir auch gut vorstellen. Was ich allerdings nicht so gern hätte, wäre jetzt mehr als eine Erzeugungs-Möglichkeit für die GUI-Items zu haben. Ich fürchte, sonst verzettle ich mich. Daher bitte ich, eine von den beiden Möglichkeiten auszuwählen.

Traude

Lossy Ex schrieb:


Die VCL war meine erste Station. Ich wollte wissen, welche Struktur sie bevorzugt. Es beruhigt mich etwas, dass die VCL ebenfalls Bäume verwendet, was das Zeichnen anbelangt. Das ist ja schon mal was. Unsere eigene interne Verwaltung steht auf einem anderen Blatt. Wir müssen uns hier nicht an der VCL orientieren.
Traude

Sidorion schrieb:



So wollen wir das auch machen. Allerdings liegt zwischen GUI und Opengl noch ein Wrapper um einfach eine andere Grafik-Library "unterschieben" zu können.

Das war ein Windowsprogramm, mit wglMakeCurrent? Mich würde ja interressieren, wie das in Linux geht.
Traude

Ja wars.
Evtl. hat die SDL da was zu bieten, bin da aber noch nicht so firm, in Sachen Linux garnicht (also firm meine ich ). Wenn da eh ein Wrapper zwischenliegt, soll der sich gefälligst um sowas kümmern

_________________
Manchmal sehen Dinge, die wie Dinge aussehen wollen, mehr wie Dinge aus, als Dinge.
<Esmerelda Wetterwax>
Es kann vorkommen, dass die Nachkommen trotz Abkommen mit ihrem Einkommen nicht auskommen und umkommen.

Ich wäre da für Fall 2, das würde aber mit einer List komfortabler gehen

@Evil-Devil:
Kannst du das mit der "proklamierte Variante von Parent -> Child (Parent) -> Child" nochmal erklären? Weil zumindest nach meinen Gedanken arbeitet die GUI so.


Kannst du das nochmal detailierter erklären? Weil ich bis jetzt die Nachteile der Baumstruktur noch nicht gesehen habe.

@OOP:
FPC unterstützt auch OOP und daher sollten wir auf OOP setzen.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄