Eben. Ich würde sagen, verzettel Dich nicht zu tief beim Abschauen von der VCL. Unser Ansatz ist doch ein etwas anderer, da die einzelnen Komponenten ja keinen eigenen DC oder RC kriegen. Von daher: bleib besser bei der Baumstruktur.

p.s.: Denkbar wäre auch folgendes: Die Subelemente auch über Namen zugreifbar machen () Dann kannst Du in der Getter/Setter-Methode fragen, ob index ein Int oder string ist und entsprechend reagieren. Dann ginge nämlich folgendes:
und die Elementnamen müssten nurnoch innerhalb des übergeordneten Elements eindeutig sein.

_________________
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 hab gestern das TAppWindow um Linux erweitert. Es nutzt die xlib um ein Fenster zu holen und zu verwalten.
Also wer auf ein eigenenes Fenster und Context verzichtet und nicht das Control von der GUI verwendet, kann mit der TAppWindow sich abängigkeiten wie z.b. SDL und SDL_TTF sparen.

Meine Prüfungszeit hat gestern begonnen und ist auch schon fast wieder rum, ausserdem will ich und Traude nun ein gemeinsamen Code schreiben(der Vortakt zum Release).

Ich hab mir für die release gedacht, alle widgets in eine unit dglstdctrl.pas zu packen und nicht jedes widget in eine einzelne unit.
Dies schmällert die übersicht vom Code aber macht auch das einbinden der widgets leichter. Ist blöd, wenn man in eine Unit erstmal 20 uses reinpacken muss um dann die Komponenten nutzten zu können.

Für den releasecode hab ich mir auch gedacht dglcanvas ein bischen zu zerpflücken.
-dglcanvas.pas
-dglcanvasgpu.inc
-dglcanvascpu.inc
Wobei dglcanvascpu/gpu.inc in unterordner include/[os]/ kommen wobei os dann für das betriebssystem steht.
So kann man die genutzten APIs wesentlich leichter austauschen und variieren.
Wenn wer z.b. sein eigenen Fontmanager oder Texturmanager nutzten will, kann er in den inc files den eigenen eintragen und für ein anderes System den schon existierenden nutzten.

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

Projekte: https://github.com/tak2004

Hallo Lossy eX,

Wir arbeiten im Augenblick mit einer sehr einfachen Struktur. Wir haben zwar einen Multiwindow-Ansatz, aber ich sehe das so (und ich glaube, Tak sieht das ganz ähnlich), dass mehrere Betriebssystem-Fenster nur aufgemacht werden sollten, wenn sie thematisch ganz verschieden sind, Delphi ist ein gutes Beispiel: das Hauptfenster mit den Befehlen ist ein schmales Fenster am oberen Bildschirmrand, der Objektinspektor ist ein eigenes Fenster, der Code-Editor ist ein eigenes Fenster...

Aber das ist nur unsere persönliche Meinung. Das Aufmachen von Betriebssystemfenstern unterliegt keiner Beschränkung. Das kann der User halten, wie er will.

Das hat den Vorteil, dass ich mein Arbeitsfenster maximieren und über die Taskleiste trotzdem leicht auf die anderen Fenster zugreifen kann: ich verlasse mich hier aufs Betriebssystem, immer in der Hoffnung, dass andere Betriebssysteme etwas Ähnliches haben.

Aber wir müssen für einen simplen Button kein eigenes Fenster aufmachen.

Lossy eX schrieb:


Das ist bei uns eigentlich nicht so. Nach dem derzeitigen Konzept ist es ein Mischsystem:
Mehrere Betriebssystemfenster sind möglich, aber wenn man nur eins hat (auch ein selber aufgesetztes), ist es auch OK (siehe Beitrag von Tak oben). Innerhalb der Betriebssystemfenster zeichnen wir soviel wie möglich selbst (stimmt nicht ganz: wir "lassen zeichnen" über die Wrapper). Wir nehmen damit dem Betriebssystem ein Stück Kontrolle weg und übergeben die Verantwortung dem User, weil der sich jetzt entscheiden kann, welches System er über die Wrapper mit dem Zeichnen beauftragt (natürlich muss er damit im Einklang mit dem Betriebssystem bleiben).

Ich glaube ich hatte mich falsch ausgedrückt.

Was ich damit aber meine ist, dass die VCL unter Windows nicht ausschlaggebend für die Struktur der Elemente (Fenster, Buttons) ist. Sondern, dass sich diese Struktur im Inneren von Windows befindet. Also sollte man nicht zu fest davon ausgehen, dass die VCL schon alles ist. Die Strukturen in der VCL sind zu großen Teilen Vereinfachungen der API und Verwaltung der eigenen Objekte (Instanzen der Komponentenklassen).

Lossy eX schrieb:

Ich weiss jetzt nicht genau, was Du mir sagen willst. Also ich meinte das mit dem Selberzeichnen so: User drückt Button -> Betriebssystem berichtet Mausklick an übergeordnetes Fenster (Fensterhandle, Mauskoordinaten). Vom selbstgezeichneten Button weiss das Betriebssystem natürlich nichts. Das Fenster muss jetzt selber wissen, wer mit dem Mausklick gemeint war. Ich hoffe, ich habe nicht irgendetwas nicht berücksichtigt oder vergessen.

Dein Beitrag in der Nacht war sehr auf die VCL und deren Aufbau bezogen. Das hat jetzt nichts speziell mit irgendwelchen Techniken zu tun was wie wo gemacht wird. Sondern von mir lediglich der Hinweis, dass die VCL was die GUI von Windows angeht eher eine untergeordnete Rolle spielt. Weil sie halt nur eine Kappselung der API ist.

Aktuell gibt es nur eine anbindung an winapi und xlib. Diese lassen ein fenster erstellen und ein context holen.
Die zeichenfunktionen laufen aktuell auf eigene kappe, also opengl und gdi übernehmen das zeichnen von flächen.
Wir nutzten keine Vorgefertigten Komponenten von der Winapi und xlib.
Denn dann würde ja die einheitlichkeit verschwinden, so sind alle widgets einheitlich gezeichnet, egal ob windows oder linux.
Wo es nicht so ganz zutrifft, ist die Schrift. Da kann es passieren, dass es ein bischen unterschiedlich aussieht.

Die Widgets sind in ein Baum angeordnet und das ist auch besser so, denn das fördert die übersichtlichkeit sowie die geschwindigkeit.
Die Gui Klasse kann TDGL_AppWindow und TDGL_GraphicControls aufnehmen und diese Klassen können alle Arten von Widgets aufnehmen.
Ein Widget kann alle arten von Widget aufnehmen.
Was bedeutet, die gui klasse besitzt mindestens eine Klasse, die weiß wie groß und welche position, sowie eigenschaften zum zeichnen kennt.
Diese Klase kann dann nur noch Klassen beherbergen, die zeichnen.

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

Projekte: https://github.com/tak2004

Naja, die Wrapper kann jemand übernehmen oder sich seine eigenen zurechtschnipseln. Wenn jemand großen Wert darauf legt, dass es überall gleich aussieht, könnte er z.B. folgende betriebssystem-unabhängige Varianten in Betracht ziehen:

- den CanvasGPU-Wrapper mit SDL aufsetzen und eine SDL-Schrift in Betrieb nehmen (EasySDL?)
- den Wrapper mit Freetype aufsetzen und eine FreeType Schrift in Betrieb nehmen
- Bitmapschriften einsetzen

Jetzt bin ich mit meiner Weisheit am Ende, aber es gibt vermutlich noch mehr Möglichkeiten.




Lossy eX schrieb

....und damit alle wilden Windows-Bocksprünge mitmachen muss.

Wahhhhh. Ich fühle mich missverstanden! Ich habe doch nie gesagt, dass irgendwer irgendwas so oder so machen muss, oder? Ich habe doch nur (mehr oder weniger direkt/deutlich) darauf hingewiesen, dass die VCL durch ihre Kappselung der eigenlichen Struktur keine wirkliche Aussagekraft hat. Denn die wirkliche Verwaltung der Elemente passiert im Untergrund in der API. Und alles was man bei der VCL sehen kann dient lediglich IHRER Verwaltung der Delphi Klassen. Das hat aber noch nichts mit den Elementen der GUI unter Windows zu tun. Und da einiges Ideen/Gedanken sehr auf die VCL fixiert waren/sind habe ich mir gedacht weist du mal drauf hin. Dieses Missgeschick wird mir sicher kein zweites Mal passieren...

Ich habe Dich schon richtig verstanden. Ich wollte nur darauf hinweisen, dass die VCL (als Wrapper der Windows-API) nicht als eigenständige Anwendung agiert und damit eben - alle Windows Bocksprünge mitmachen muss. Jemand, der ein Windows Programm mit Delphi schreibt, sollte sich darüber im Klaren sein. Ich zum Beispiel habe mich dafür so lange nicht interessiert, bis ich mit den Programmieren von Spielen angefangen habe. Dann merkt mans allerdings ganz schnell (mein erster Versuch, eine 3D-Anwendung zu schreiben, war eine sich tatsächlich drehende Kugel mit VCL-Mitteln, wobei ich die Bleuchtung selbst berechnet habe - der Code existiert nicht mehr).

Ich muss mal kurz zwischenfragen: Benutzt Ihr mein XML-Streaming-Interface? Wenn ja, muss ich mal ne neue Version hochladen, weil ich hab noch ein, zwei grobe Schnitzer entdeckt.

_________________
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 gibt eine Klasse TDGL_DataInterface und diese sorgt für die komunikation zwischen gui und aussenstehenden code, also z.b. ein XML loader/saver.
Wir wollen es dem User überlassen, sich ein XML Loader zu schreiben, da erstens der Code geparst werden müsste und damit wieder eine abhängigkeit von unserer seite kommen würde und 2. könnte es ja sein, das der nutzer sein xml format anders aufbauen will. Wir könnte in das zusätzlichen Stuff ein solches Interface hinzu legen.

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

Projekte: https://github.com/tak2004

Muss ja nicht sein, ich hatte die Unit nur Traude mal zur Verfügung gestellt, damit sie sichs ansehen kann und ich wusste eben nicht, ob sie's (man beackte die korreckte Verwendung des Auslassungszeichens ) integriert hat. Und da diese Version eben einen Fehler hatte, hab ich mal lieber nachgefragt.

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

Sidorion schrieb:


Ich habe in der Zwischenzeit einen Dataprovider geschrieben, und gerade heute eben hochgeladen. Das Ding funktioniert noch nicht mit XML, aber ich habe mal CSV benutzt, und es ist im Entwicklungsstadium. Als Vorlage dafür habe ich mehrere Quellen benutzt, unter anderem auch Deinen Code. Ich habe es zig-mal auseinandergenommen und neu zusammengesetzt, einerseits, um es so einfach wie möglich und trotzdem so effektiv wie nötig zu machen. Ich habe mich zuletzt dafür entschieden, ein RTTI-Objekt zugrundezulegen, das über seine Properties selber Auskunft geben kann, also einen einfachen Zugang für viele Anwendungsmöglichkeiten geschaffen, den nicht nur der Dataprovider benutzen kann. Der Dataprovider "befragt" das RTTI-Descendant dann nach dessen Published Properties. Mit diesem Ding sollte man jetzt leicht in XML/Binary/Text etc. Daten streamen können.

Ich wäre besonders daran interessiert, ob Du das Teil grundsätzlich als nützlich betrachtest. Ich habe eine kleine Demo dazu geschrieben und auf Taks SVN geladen. Wenn Du möchtest, lade ich das Demo hier auch hoch.
Traude


Nachtrag: ich merke gerade, ich habe Deine Frage nicht beantwortet.

Nein, ich habe Deinen Code nicht einfach eingebaut. Aber ich habe beim Schreiben des Dataproviders immer drauf "geschielt".

Noch ein Feature was bisher glaube ich noch nicht angesprochen wurde, ist Übersetzbarkeit. Imo solle jede klasse diejenigen ihrer Felder die Übersetzt werden irgendwie kennzeichnen, bzw auflisten können. Die text/hint-eigenschaft kann man wie in delphi in einer sehr frühen klasse als protected deklarieren, selbst wenn sie da noch nicht gebraucht wird. In Delphi verwenden alle von TControl abgeleiteten Elemente die Text(=Caption) besitzen die selbe Eigenschaft