Jepp hat ein Grund.
Es kommt des öfteren vor, dass es einfach zuviel aufwand ist eine Klasse an zu legen um ein simples ondraw oder onclick oder anderes event zu zuweisen. Es gibt ja zum Glück TMethode
Es besteht aus 2 variablen, klasse und funktionspointer.
Im fall von einer Procedure kann man einfach die Klasse nil setzen aber man muss dann im eventaufruf darauf achten.
Wenn also beim aufruf die klasse nil ist muss man den funktionspointer passend casten und sonnst einfach TMethode aufrufen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Meine Lieben,
ich werde mich für heute verabschieden, muss meinen hausfraulichen Pflichten nachkommen.

Ich möchte aber jetzt noch festhalten, was mir bisher klar ist, und was noch nicht:

Funktionen des GUIItems:
1) Grundsätzliche Implementierung als TreeNode (TObjectList), was noch fehlt, sind die Implementierungen der einzelnen TREE-Funktionen: Draw, SetVisible, etc., sollte kein besonderes Problem mehr sein
(@Edit habe gerade gemerkt, dass das missverständlich formuliert ist: es ist nicht von TTreeNode abgeleitet sondern von TObject und realisiert seine Tree-Funktionen ausschliesslich über die TObjectList)
Das Konzept ist meiner Meinung nach fertig

2) Implementierung des "Receivers", soweit sie das TGUIItem betrifft. Mein Konzept habe ich Eurem Konzept angepasst: die User-Events werden über Methoden/Prozedurzeiger geleitet, für seine eigene Eventbehandlung hat das TGUIItem eigene Methoden, welche dann die User-Eventhandler aufrufen.
Das Konzept ist meiner Meinung nach fertig

3) Zeichenfunktion: fehlt noch, im TGUIItem sollte das nur eine TREE-Funktion sein (das TGUIItem muss dafür sorgen, dass sich auch alle seine Children zeichnen),
Das Konzept ist meiner Meinung nach fertig

4) Lade/Speicherfunktion: Noch offen (Vorschlag: in ein Objekt auslagern)

5) Errorhandling: Mit Exceptions (kein Konzept nötig?)

Sonstige Funktionen:
1) Wie empfängt der GUI-Manager Events von außen? (wie TGUIItem/anders): noch offen
1) Weiterleitung der Events im Baum: noch offen
2) Implementierung abgeleiteter GUIItems: Vorschlag für ein Konzept: Festlegung von einem Set genügt
3) Einbinden des Theme-managers: noch offen
4) Einbinden der Skriptsprache: noch offen

Und last not least: Danke für Eure Hilfe.
Traude

Fehlerhandling:
Ich denke mal das Exceptions wirklich ein unumstrittendes Thema ist.
Alle anderen möglichkeiten sind aufwendiger und machen dann später Probleme, wenn jemand ein eigenen Logger nutzen will.

Komponenten Set:
Zum Thema Komponenten Set hab ich hier was von XD_GUI.
http://tak2004.dyndns.org/share/gui.pdf
Ich denke die Widgets, die da aufgeführt sind, sollten völlig ausreichen.

TGUIItem aufbau:
Ich hab im Anhang mal eine Grafik gelegt, die TGUIItem hab ich mit dem gefüttert was ich als fest stehend aufgeschnappt hab.

ScriptSprache:
Für ein Scriptsupport ist nur eine Sache zu tun.
Man legt jeweils ein Property pro genutztes Event an und das ist vom Typ String.
Der Programmierer kann dann eine Methode in OnClick oder ähnliches legen.
Wenn dann der event aufgerufen wird, wird die Methode vom Programmierer aufgerufen und entweder der Sender oder der String mit übergeben.
Somit kann in der Methode dann das nötige getan werden um dann mit Hilfe des Strings die funktion im Script zu finden und auf zu rufen.
Alle Published Properties kann der Programmierer verwenden um sie selber in die eigene Scriptsprache zu speisen.

So hab ich es in meiner neuen GUI gemacht und damit ist sie unabhängig von einer Scriptsprache.
Das tolle ist, man kann im Script dann über das property mit dem ScriptEventNamen zur laufzeit eine Scriptfunktion zuweisen.

Theme:
Hier zu muss auf jedenfall geklärt werden , wie er funktionieren soll.
-kann nur ein Theme zugelassen werden
-können mehere Themes gleichzeitig verwendet werden
-wenn ja wie wird entschieden welches genutzt wird
-was ist, wenn ein Theme einige Widgets nicht bedient
-soll es ein Fallback auf ein zeichenroutine geben

Ich hab es in XD_GUI so gelöst.
Die Daten liegen in einer XML File vor.
Beeinflussbar sind borderleft, borderright, bordertop, borderbottom und Image.
Diese Werte können Elementen zugewiesen werden, wobei ein Elemente ein Teil vom Widget ist(wie Titelleiste von Window).
Der ThemeManager ist im GUIManager verankert und TXD_GUI_Widget kann dann so darauf zugreifen.
Wenn für ein Element des Widgets keine Werte exitsieren wird auf das Fallback zurück gegriffen.

Fallback
http://tak2004.dyndns.org/share/screenshots/x-dream/window9.JPG

Theme
http://tak2004.dyndns.org/share/screenshots/x-dream/newgui.PNG

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo Tak

Danke für detaillierte Ausarbeitung. Ich werde unten noch was dazu sagen.

Ich bin gestern Abend in mich gegangen und habe mir Folgendes gedacht: wenn ich so weiter mache, schmeisst Phobeus mich raus. Und mit Recht. Ich bin eigentlich der Schriftführer und sollte mitschreiben. Daher habe ich mir das, was ich gestern noch hinterlassen habe, in ein Dokument gepackt, weil das das letzte Mal so gut funktioniert hat.

Dieses (beiliegende) Dokument ist nicht fertig. Es ist für mich eine Hilfe, zu sehen, wo wir uns grade befinden und in welche Richtung wir gehen. Wir haben zwar die Überschrift "Brainstorming", aber man muss es ja nicht übertreiben. Es ist zwar ein Grobkonzept, aber wenn gute spezielle Ideen fürs Feinkonzept aufkommen, werd ich sie auch dahinein packen. Hoffe, damit das Procedere abzukürzen.

@Tak: Deine detaillierten Vorschläge (nicht nur diese, auch Vorschläge von früheren Beiträgen) werde ich, wenn bis heute abend um 18 Uhr niemand eine Änderung vorgeschlagen hat, ins Konzept einarbeiten; vermutlich habe ich beim Einarbeiten noch Fragen dazu.

Das überarbeitete Konzept stelle ich dann wieder zur Verfügung. Wenn alle Fragen damit beantwortet sind, wäre das Grobkonzept fertig und wir können das Brainstorming abschliessen.
Traude

Ich finde, wir sollten der Traude mal ein Trullala für ihre eifrige Arbeit gönnen.
Also Alle:
[sing]
Deeeeeeer Traude sei ein Trullala, Trullala, Trullala, der Traude sei ein Trullala, Tru-la-laaaaaa,
Uuuuuuund obendrein ein Schätträtä, Schätträtä, Schätträtä, und obendrein ein Schätträtä, Schnä-trä-tääää
[/sing]


p.s.: Wir brauchen ein Noten-Tag

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

Ihr braucht Urlaub, aber sicher kein Noten-Tag.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Danke für die tollen Ovationen.

Ich hab das Dokument heute vormittag gemacht . Gestern Abend hab ich mich damit vergnügt, das, was in dem Konzept steht, in Delphi Code umzusetzen. Aber verrat mich nicht! Wenn Tak das liest, krieg ich wieder eine drübergezogen.
Traude

Tak, bei deinem Diagramm versteh ich nicht wieso ein Panel auf gleicher Ebene steht wie ein zb. ein Label. Aus meiner Sicht ist ein Panel ein Dekorationsloses Element das nach Belieben erweitert werden kann. Zb. zu einem Label und aus dem Label kann man durch das hinzufügen einer Border einen Button machen...

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

Welche Schichten ?
Die eine Grafik ist ein Klassendiagram nach UML2 standard und das andere ist einfach nur eine Visualisierung von XD_GUI Klassen.

Ich wollte mit der einen Grafik zeigen welche Kompos so praktisch sind, dass man sie implementieren sollte.
Die 2. Grafik sollte nur zeigen wie TGUIItem bisher aussieht und das daraus die weiteren Widgets abgeleitet werden.
Wie am ende die Widgets abgeleitet werden ist ne sache für sich.

Also ich denke an folgende Komponenten:
-Button
-Panel
-CheckBox
-RadioBox
-Label
-Image
-Window
-EdidBox
-ComboBox
-ListBox
-Scrollbar
-Progressbar
-TreeList
-Memo
-TabSheet
-DropDownMenü

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ok. War auch bloß eine Frage. Welches UML Tool macht so "bunte" Bilder?

@Komponenten:
Hab ich soweit nichts hinzuzufügen. Werd mich am Wochenende dann mal ans UML machen. Basierend auf den Daten die hier im Thread stehen.

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

OpenOffice Draw macht so bunte Bilder ^^.
Ich mach das per Hand, also mit richtig viel liebe.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Wieso eine Scollbar von einem Panel abgeleitet sein soll versteh ich jetzt gerade nicht. Ein Panel ist ein Container, eine Scollbar sicher nicht. Die Grundlegende unterteilung der Klassen (Also Container, Textfelder, Eingabeobj., etc.) ist bei Java (Swing) recht verständlich gemacht. Das kann man sich ja mal angucken. Im VisualEditor sind die auch gleich passend Gruppiert. Wie die dann untereinander noch abgeleitet werden ist dann der eigenen Creativität überlassen.

Ich hab auch ne GUI geschrieben, die ich momentan verwende. Das Klassenkonzept gefällt mir sehr gut. Allerdings verfügt sie über keinen Scriptsprache und auch über keinen Editor. Ich erzeuge die Fenster zur Laufzeit alle Manuell. Das ist rein vom Programmieren her das leichteste gewesen. Allerdings sehe ich den Vorteil eines Editors ein. Saschas Editor war ziemlich beeindrucken. Ich wollte sowas auch machen, allerdings war der Aufwand in meinen Augen zu groß um es, wie Sascha sagte, mal schnell zusammen zu bauen.

Außerdem habe ich noch einen Schönheitsfehler in der GUI. Ich habe den Koordinatenursprung unten links gemacht. Das war, wie sich herausstellte, nicht so clever. Ich werd das mal umbauen müssen.

Skinning ist durch das austauschen der Textur möglich.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Eigentlich kann jede Komponente automatisch ein Container sein. Das macht die Sache ja nur einfacher. Und die Scrollbar enthält zumindest 2 Buttons und eine Leiste.

Hallo Flash,
mich würde interessieren, welche Nachteile Du bei einem Koordinatenurspruch unten links festgestellt hast. Weil ich das eigentlich auch mal so vorhatte.
Traude

Du musst alles was du hast erst einmal umrechnen. Höhe - YKoordinate. Das ist mühsam und eigentlich auch unnötig kompliziert. Wenn du einen Texturenloader benutzt der die Textur mit der ersten Zeile zu erst ablegst dann kannst du diese Koorinaten auch direkt so an OpenGL übergeben. Soll bedeuten. Vertextkoordinate ist obenlinks ausgerichtet und die Textur auch. Ich persönlich benutze ausschließlich diese Methode. Einfach weil ich es komisch finde etwas auf den Kopf zu stellen was nicht der Fall sein müsste.

Allerdings muss man fairerweise dazu sagen. OpenGL Koordinaten (Y) arbeiten normalerweise von unten nach oben. Für viele ist es einfacher das so zu handhaben. Und es hat sich ein gewisser "Standard" durchgesetzt. Die Texturkoordinaten in einem 3ds stehen auf dem Kopf. Genau so auch alle Glu/Glut Funktionen. Dabei stehen auch alle Texturkoordinaten auf dem Kopf. Liegt wohl auch daran, dass Bitmaps mit der letzten Zeile zu erst in der Datei abgespeichert werden und windows das intern auch so macht.

Allerdings verlangen Cubemaps, Texturen die mit der ersten Zeile zu erst abgelegt wurden. Dabei werden ja die Koordinaten automatisch von OpenGL berechnet. Was mich in meiner Theorie wiederrum bestärkt, dass es alle anderen "falsch" machen. Falsch gibt es leider nicht. Es ist halt alles sehr flexibel. Weswegen es kein Richtig oder Falsch gibt sondern nur Geschmackssache. Unnötig kompliziert ist halt auch Geschmackssache.

Aber ich glaube ich schwafel gerade wieder eine Runde. Ob das an dem Rotwein liegt? Neeee. Liegt wohl auch daran, dass ich mich deswegen schon reichlich auseinander gesetzt habe. Wegen meinem Texturenloader. Dort hatte ich es ausversehen richtig gemacht und mittlerweile schwöre ich drauf.