Und wie willst Du es mit VCL benutzen? Ich steh auf der Leitung.

Keine ahnung ... es sollte halt in Pascal geschrieben sein

Hier die Beispieldateien:

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

Im Moment verlangt der Delegat noch ein TComponent als Owner, weil ich in meinem Projekt TComponent genutzt habe, um das Plattschlagen zu automatisieren, man könnte das aber auch umstellen, allerdings muss dann das entsprechende Objekt mit w+ compiliert werden, damit es die RTTI liefert.
Insofern ist das Beispiel etwas fehlerhaft, weil hier TPart nicht von TComponent abgeleitet ist. Ich habs gestern aber 'flutsch und weg' zusammengestellt.

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

Mein letzter Monsterbeitrag, versprochen

Wenn Ihr einverstanden seid, stelle ich den Text für die Lade/Speicherfunktion so ins Grobkonzept:

1.5 Lade/Speicherfunktion
Das TGUItem und seine Descendants tragen die Verantwortung, welche Daten zu laden und zu speichern sind, selbst. Sie sollen sich dabei aber einer Schnittstelle ("Datenprovider") bedienen, die das Speichern und Laden der übergebenen Daten in einem ausgewählten Datenformat selbständig erledigt. Das voreingestellte Speicherformat (Default-Format) ist XML. Der Datenprovider ist so zu erstellen, dass er leicht durch einen anderen Datenprovider, der ein anderes Speicherformat ermöglicht, ausgetauscht werden kann. Das Laden/Speichern ist eine TREE-Funktion.

FEINKONZEPT: Das GUI soll Zugang zu seinen Laufzeit-Typinformationen (Runtime-Type Informaton,"RTTI") erhalten, indem es von einem TRTTI-Objekt abgeleitet wird, das diesen Zugang durch seine Methoden anbietet (Kompilierung mt {$M+}). Konversionen/Kompatilitätsprobleme mit der Delphi-Visual Component Library(VCL) sind zu vermeiden.

---------------------------------------------------------------------------------------------------------------------


Dann habe ich noch folgende offene Punkte im Grobkonzept, die ich Euch jetzt einfach an den Kopf werfe:

4. FUNKTIONEN, DIE DAS GESAME SYSTEM BETREFFEN

1) Wie empfängt der GUI-Manager Events von außen?(wie TGUIItem/anders)
Das war (bei meinem ersten Konzept, vor vielen Seiten) ein Problem, denn ich hatte einen Variant-Record drin, der dem GUI-Manager übergeben wird. Der Variant-Record wurde nicht gut aufgenommen. Im Augenblick ist es so, dass der GUI-Manager auch einfach ein TGUIItem ist. Also erbt er auch alle Eventhandler des TGUIItem. Es wäre auch eine Möglichkeit, es einfach dabei zu belassen. Wenn ihr weder meinen Variant-Record noch die detaillierten TGUIItem-Eventhandler wollt, müsst Ihr was vorschlagen. Wenn mir keiner was vorschlägt, nehme ich die Eventhandler. Das bedingt, dass vor der Übergabe die Events für den Manager "mundgerecht" aufbereitet werden müssen.

2) Optimale Weiterleitung der Events im Baum
Das möchte ich im Grobkonzept nicht weiter ausführen, weil das unwillkürlich in ein Feinkonzept ausartet. Ich schlage vor, der Programmierer implementiert das, was ihm am besten erscheint. Viel Auswahl dabei wird er ohnehin nicht haben: möglichst ein Direktzeiger, wenns nicht geht, den kürzest möglichen Weg im Baum. Der Text fürs Grobkonzept lautet dabei einfach: "Bei der Weiterleitung der Events im Baum ist der Optimierung der Geschwindigkeit oberste Priorität einzuräumen."

3) TGUIDescendants: Vorschlag für ein Konzept: Festlegung von einem Set genügt
Mein Vorschlag: ich nehme Taks Set, scheint mir sinnlos, darüber viel zu diskutieren, über Details kann man später immer noch sprechen. Die Darstellung ist an Windows orientiert.

4) Einbinden des Theme-Managers

Was soll der Themes-Teil können:

a) ÄNDERN DES ERSCHEINUNGSBILDES ("Look"):
IDEE für einen Look-Manager: Der LookManager verwaltet zentral bestimmte Objekte, die zum Erscheinungsbild eines TGUIItems beitragen. Zunächst dachte ich dabei nur an Textur und Font, aber warum eigentlich nicht auch solche Dinge wie Farbe, Strichbreite und Zeichenroutine? (@Tak: das schliesst auch solche Dinge wie borderleft, borderright, bordertop, borderbottom usw. ein). Mit einer solchen Verwaltung kann man dem ganzen GUI-Baum eine einheitliche Uniform anziehen. Man sollte dem einzelnen GUI-Element aber auch erlauben, aus der Reihe zu tanzen (ein "Nonkonformist").
Wenn ich den Look-Manager anweise, eine zentral verwaltete visuelle Eigenschaft zu ändern, ändert sie sich im ganzen Baum, braucht nicht mal eine Tree-Funktion zu sein, weil alle "Konformisten" einen Direktzeiger auf diese Eigenschaft haben. Dazu braucht das Programm auch gar nicht neu gestartet zu werden. Die Änderung ist einfach beim nächsten Zeichnen mit dabei. Eventuell ist der Look-Manager auch bloß ein Methoden-Set des GUI-Managers, könnte man vielleicht leichter zugreifen.

Über die Datenstruktur von Themes habe ich mir noch nicht den Kopf zerbrochen, das ist abhängig von den Eigenschaften des GUI-Items, die stehen auch noch nicht fest.
Taks Grafik des TGUIItem aus einem früheren Beitrag auf Seite 12: ja, seh ich auch so. Fehlt natürlich noch etliches, weil einiges erst zutage kommt, wenn man im Konzept weiter fortschreitet. Ob die Descendents so sind, kann und möchte ich jetzt eigentlich noch gar nicht sagen. Manchmal sind Dinge, die ganz offensichtlich erscheinen, wenn mans im Detail anschaut, völlig anders.

Frage von Tak: -was ist, wenn ein Theme einige Widgets nicht bedient: ==> Fallback auf eigene Zeichenroutinen

Frage von Tak: -können mehrere Themes gleichzeitig verwendet werden: Da müsste eine Liste von Themes angelegt werden (jedes Theme ein Datensatz). Dann könnte der Benutzer darin "blättern", dh.bei Anwahl eines Themes sieht man es auch schon auf dem Bildschirm, das müsste eigentlich - wegen der Direktzeiger - möglich sein. GELADEN ist allerdings nur das, was grade angezeigt wird. Das heißt, beim Anklicken eines Theme-Datensatzes müssen jedenfalls die zugehörigen Texturen und Fonts geladen werden.

b) ÄNDERN DES VERHALTENS ("Feel"):
In professionellen Anwendungen ist offenbar auch das Ändern von Events dabei, das heißt "OnMouseClick" ereignet sich etwas anderes. Das bedingt m.E. die Zuweisung eines neuen Event-Sets (ein Event-Manager?). Darüber müsste ich aber noch nachdenken, dafür habe ich mir einfach noch nichts überlegt. Bin auch leider ein Windows-DAU und kenne nur dieses. Kann ich das auf die lange Bank schieben? Scheint mir etwas viel für Version 1.0.

5) Einbinden der Skriptsprache (Vorschlag Tak)
Derzeit muss ich da passen. Hab einfach noch zu wenig Kenntnis über Lua.
Daher werden ich den folgenden Absatz von Tak ins Konzept einarbeiten.

Tak schrieb am 8.Dez.2006:




So das waren die noch offenen Punkte aus dem Grobkonzept. Wenn die geklärt sind - und das sollte eigentlich nicht allzu schwer sein, - dann bin ich mit dem Grobkonzept fertig. Ich bräuchte jetzt zum obigen von Euch also ein bissl Feedback. ("Ja" genügt )
Traude

Hallo Sidorion,
hab mir Deine Datei zwar gestern runtergeladen, bin aber noch nicht dazu gekommen, es anzuschauen. Da bin ich jetzt grade dabei.

Hallo Traude,
obwohl ich im Moment 'nur' Brainstormer für das Projekt bin, sag ich mal "Ja"

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

Hallo Sidorion,

die Zeile "Result:=IXMLStream(oPart).ReadFromXML(oNode);" könnte man so ins Deutsche übersetzen:

Schnittstelle IXMLStream, vertreten durch das Objekt oPart, lade Werte mit deiner Funktion ReadFromXML für einen Childknoten, wobei der Parentknoten oNode ist.

Ich hoffe, das so richtig verstanden zu haben.

Dann habe ich mir die Funktion ReadFromXML in der Unit XMLStream angesehen. (Ich stells jetzt hier nicht rein, wenns jemanden interessiert, muss er sich den Code aus Sidorions Beitrag runterladen.)

Du benutzt die Funktionen aus der Unit TypInfo (die in Delphi nicht wirklich offziell dokumentiert sind) um an die Informationen heranzukommen, die du hier brauchst. Deshalb ist es wohl notwendig, die ReadValue/WriteValue-Methoden als Klassen-Funktionen zu definieren? Das Ding ist eine ganz schön harte Nuss. Ich habs sicher nicht bis auf den letzten Ausdruck durchdrungen, nur vom Prinzip her. Ich will in die gleiche Richtung wie Du, allerdings wäre es mir lieber, den Benutzern (und in diesem Fall sind mit "Benutzer" auch Programmierer gemeint), nicht ganz so starken Tobak zu servieren (we are looking at the inner engine of the delphi universe.....). Ein Kompromiss wäre z.B. folgender: zunächst muss man wissen, welche TypInfo-Funktionen für das TGUIItem wirklich gebraucht werden. Dann könnte das TRTTI-Objekt diese Funktionen wrappen, und das TGUIItem wird davon abgeleitet. Damit hätte man das ganze ein wenig kanalisiert und abgefedert. Was meinst Du dazu?
Traude

Das hast Du richtig verstanden, zumindest ungefähr Der Parentknoten ist sozuagen die Property des Objektes selber. Darunter befinden sich dann die Propertys des 'Kindobjeks', d.h.: das Kindobjekt benutzt den Knoten, als wie wenn er die Root des XML-Dokument wäre (alles darüber geht es nix an). Genaus kümmert sich das 'Elternobjekt' nicht darum, was innerhalb den Knoten steht (geht es nix an, thema schwarzer Kasten)

Dass der Delegat so aufge'pustet' ist hat damit zu tun, dass das Lesen/Schreiben der einzelnen Property-Typen doch sehr ähnlich ist und ich nicht jedesmal den selben Code hinschreiben wollte. (wann immer eine Codezeile doppelt steht, lohnt es sich eine Prozedur/Funktion defür zu schreiben, hilft gegen copy+paste-Fehler)
Nachdem diese lese-und schreib- funktionen auf keinen Member des delegaten zugriffen, hab ich sie als class-function definiert, damit man zur Not, wenn man den Delegaten nicht einsetzen will (selber parsen) trotzdem diese Funktionen benutzen kann (TXMLStreamDelegate.ReadValue rufen, ohne Instanz zu haben). Man hätte natürlich auch globale Funktionen nehmen können, aber da bin ich kein Freund von.
Dass die lese-schreib-funktionen klassenfunktionen sind, hat also garnix mit der RTTI zu tun und hätte problemlos anders geregelt werden können, ich fands einfach aufgeräumt so . Sie sind praktisch nur dafür da, nen Integer, String, enum usw von und nach XML zu übertragen.

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

Du benutzt mir nix dir nix Klassenfunktionen ohne wirklichen Bedarf dafür?
Du hast Nerven, eine alte Dame so zu schocken.

Klassenfunktionen sind doch nur Funktionen, die man rufen kann, ohne eine Instanz zu haben. Was ist daran denn so mystisch?

.. aber wenn ich gewusst hätte, dass Dich das so aus dem Ruder wirft, hätte ich globale Funktinen genommen

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

Hab eben ein zartes Gemüt



Wie dem auch sei, ich verabschiede mich für heute. Ich stelle morgen vormittag das vervollständigte Grobkonzept wieder rein.

Wenn ich heute abend aus der Uni raus bin, werde ich noch ein bischen genauer schreiben aber erstmal wollte ich eine sache los werden. Sobald man eine Klasse von TPersistant ableitet ist die Klasse mit RTTI daten ausgerüstet.
Das ist auch der Grund wieso TComponent von TPersistant abgeleitet ist und wieso meine TXD_RTTI auch von dieser Klasse abgeleietet ist.

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

Projekte: https://github.com/tak2004

Guten Morgen Tak,

Tak schrieb:


Das stimmt. Aber wenn man die Methoden von TPersistent gar nicht braucht (z.B. DefineProperties etc.), dann genügt es, ein Objekt mit {$M+} zu kompilieren, um den gleichen Effekt zu erzielen: siehe mein Beitrag auf Seite 13, zweiter Beitrag von unten

Ich stelle jetzt das Grobkonzept wieder rein. Die Fragen die ich hatte sind alle beantwortet worden, und ich habe dem Konzept eigentlich nichts mehr hinzuzufügen. Ich gebe damit zurück an Dich.
Traude



P.S. Bitte sieh Dir den letzten Teil über die Skriptsprache an und sag mir, ob das so stimmt, was ich geschrieben habe.

Zum Thema ThemeManager könnten wir uns auch an Delphi/Windows anlehnen: Da gibts die Unit themes, die ein singleton namens ThemeManager bereitstellt.
Diesen kann man dann beauftragen, bestimmte Komponententeile, wie Button, Button gedrückt, text usw zu zeichnen. Die GUI-Elemente selber können quasi nur den Fallback, sobald ein ThemeManager da ist, übernimmt dieser alle Zeichenvorgänge, das GUI-Item sagt ihm nur, was er wo hinzeichnen muss.

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

Mit Punkt 4 habe ich ein kleines Problem.
Interne Fehler sollten als Exception abgegeben werden und von einem Error Handler verarbeitet werden.
An diese Schnittstelle wird wieder ein Datenhandler gehangen, der dann die nötige ausgabe auf das gewünschte Medium gibt.

Nun noch ein bischen neues.
Ich hab mir gestern folgendes überlegt.
Der Grafikwrapper, stellt 2 canvas Objekte zur verfügung.
Das erste Objekt ist für GPU und das 2. für CPU.
Wenn man also eine Applikation schreiben will, die 2 Bedienfenster hat und 1 3d Bereich, dann wird ein GPUWindow und 2 CPUWindow erstellt und alle Kinder halten sich dann an das Canvas Objekt des Fensters.
Somit hat man nur 1 OpenGL Context, den man auch haben wollte und 2 normale Fenster.
Diese variante ermöglicht neben Tools auch normale Programme zu schreiben die auf allen FPC Platformen laufen und nichts mit Opengl oder DX am hut haben.

Um das zu realisieren müssten neben der normalen Fenster Komponente also noch 2 weitere spezielle Fenste Komponenten liegen. Alle Komponenten legen auf diesen beiden Komponenten auf also wie ein Root.

Das Konzept lässt nur eine möglichkeit nicht zu, unzwar MDI anwendung die GPU und CPU Teile enthalten.

Dann hatte ich noch eine Idee aufgegriffen.
Es gab ja mal kurz das Thema Dynamic Link Library und ich hab mir überlegt, dass man dies wirklich einbauen sollte.
Der Code wird an eine unit gehangen und procedural umgeleitet.
Dieser Code ist die Lib und dann könnte man ein Pascal und C/C++ header erstellen.
Somit haben wir dann auch die möglichkeit C/C++ User mit an zu locken und der mehraufwand ist sehr gering.
Mit FreePascal kann man die Libs dann für verdammt viele Platformen generieren.
Ich würde mich sofort bereit erklären, das für GP2X zu erledigen ^^.

Nun hab ich noch eine Idee zum GUI Designer.
Das Teil sollte mehr Generic sein und dazu hab ich mir ein etwas aufwendigeres Programm gedacht.
Man kann ganz normal seine GUI zusammen Klicken aber man bekommt neben ein von uns empfohlendem Format noch die möglichkeit Exporter und Importer Scripte zu schreiben. Das Tool Sollte sich wie Delphi aufbauen und die von meiner ersten Idee die 2 Fenstertypen anbieten(GPU und CPU). Wenn ich meine Game GUI basteln will, kann ich das GPU Fenster nehmen und für die GUI der Tools, für meine Games, nehme ich dann CPU Fenster. So wäre dann auch eine Korrekte darstellung der ausgabe möglich. Vom Entwickler eigene Widgets sollten dann über DLL und so weiter geladen werden.

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

Projekte: https://github.com/tak2004