https://www.linuxprofessionals.org/svn/dglgui/sandbox/prerelease/dglcanvas.pas
Hier sind die Schnittstellen für Color,Font,context und canvas drin.
Dahinter sollten eigentlich unser Codes und die GUI sollte darauf aufbauen.
color und font sind bei mir gleich geblieben und context und canvas haben in meiner version ledeglich noch ne handvoll funktionen dazu bekommen aber nichts verändert. Deswegen kann ich sehr einfach die GUI von vorige Zeichenroutinen auf DrawList(neue Variante) umstellen.

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

Projekte: https://github.com/tak2004

Und ich habe hier ein Vorschlag für eine Textur. Die Klasse TDGL_IDObject bezieht sich selbstverständlich auch auf die Schrift. Ist grauslich kompliziert geworden - tut mir leid. Vieleicht kann man das irgendwie in den Griff kriegen oder uns vielleicht darauf einigen, dass die GUI nur das Handle des Texturobjekts bekommt. Die ganze Funktionalität liegt im Konstruktor, nachher passiert mit der Textur eigentlich nichts mehr.

Um so deutlich wie möglich zu sein, habe ich noch die beiden Konstruktoren für das ID-Object und das Image dazugeschrieben.

Genau das meinte ich. Auch wenn die Font vielleicht aus dem Canvas raus gehört.
Mit dieser Unit könnte ich dann: TDGL_Font_easySDL = class(TDGL_Font) erstellen.

Jetzt stört mich nur dieses Zitat:

Inwiefern baut euer Code den nicht darauf bzw. habt ihr ähnliche Units auf denen die GUI aufbaut?

Update:
OK, ich komme hier mit dem Lesen kaum nach:
So wie es aktuell aussieht, habt ihr beide verschiedene Wege genommen. Beide sind eine Lösung des Problemes, es geht jetzt nur darum welche man nimmt. Von meiner Seite gibt es da aktuell 2 Dinge die man beachten müsste:
1. Der Wrapper sollte nicht unbedingt tief in der GUI eingebaut sein, wie es mir bei Traude aussieht
2. Der GUI muss bei Nachfolgerklassen wie bei Tak wissen welche Klasse es nehmen soll und wie man es günstig herbekommt/registriert.
Da müssten wir jetzt einfach mal schauen und überlegen.


Hey, ich würde jetzt nicht behaupten dass ich besser wäre, und dein Code ist im Vergleich zu Taks Code sehr sehr sehr gut lesbar

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

Jonas schrieb:

Nun ja, zugegeben. Aber ich hielt das für legitim, schließlich wird das auch durch die Dualität GPU/CPU verursacht. Und am Ende müssen wir ja irgendwie wieder zueinander finden.

Jonas schrieb:

Das täuscht. Der ganze Code, den ich gepostet habe, ist aus meiner Unit GraphicSupport. Davon GANZ GETRENNT ist die Unit GUI+GUIDescendants. Ich habe das GraphTool (das ursprünglich Canvas hieß und eigentlich nur ein reiner Verwalter ist) im GraphicSupport belassen, obwohl man es eigentlich auch zur GUI stecken könnte. Weißt Du noch? Man sollte die GUI auch mit einer anderen GrafikLibrary aufsetzen können. *Duck und weg*

Tatsache ist, dass obiger Code sowohl bei Tak als auch bei mir nichts mit der eigentlichen GUI zu tun haben. Du hast hier kein Krümelchen von der GUI zu Gesicht bekommen.

Jonas schrieb:

Das habe ich jetzt nicht verstanden.

Bitte berücksichtige bei der Font auch, dass ich so etwas wie DrawTextSelected brauche - für das TEdit.
Traude

Bei Tak nimmt man ja TDGL_CanvasGPU = class(TDGL_Canvas).
Jetzt ist für mich die Frage woher DGLGUI wissen soll, dass es TDGL_CanvasGPU nehmen soll anstatt TDGL_Canvas

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

Ich glaub du müsstest dir den ganzen Code ansehen um mein Konstrukt zu verstehen.
Naja ich versuch einfach mal kurz zu beschreiben wie es läuft.
Ganz Oben liegt die TDGL_GUI, welche vom User die Events bekommt und den Zeichenauftrag.
Alle events werden an die Childs gegeben die alle ihren Vater in TDGL_Widget finden.
Es gibt ganz oben im Baum eine Klasse, welche TDGL_GraphicControl ist.
Dort sind TDGL_Canvas,TDGL_Theme und RDGL_Intf(enthält je nach interface den OpenGL Context oder andere Interface spezifische dinge). Sobald ein Widget ein Parent bekommt, übernimmt es canvas und theme vom parent.
Das richtige Canvas wird durch RDGL_Intf bestimmt, wenn das Interface umgestellt wird, dann wird auch die passende Canvas Klasse geladen. Aktuell hab ich Software Interface entfernt, aufgrund der mehr aufwandes.
TDGL_Context ist eine Klasse, die zu TDGL_AppWindow gehört.
Wenn man nicht TDGL_GraphicControl auf der ersten Baumebene einbindet, dann kann man auch TDGL_AppWindow nehmen.
Diese Klasse erstellt selbständig ein Fenster, holt ein Context,stellt das Interface ein und besorgt ein Canvas.
Der Vorteil an TDGL_AppWindows ist multiwindow support, denn jedes Fenster kann ein eigenen OGL Context haben und Events laufen auch selbstständig durch. Man kann auch wie bei TForm gewohnt alle Events überschreiben.
Nun zu Zeichenfunktionen, canvas ist entweder TDGL_Canvas_CPU oder GPU(aktuell nur GPU). Die dglcanvas.pas lädt dann eine Includefile aus "./include/target-os/dglcanvasgpu.inc". Wenn man also änderungen an den Grundlegenden zeichenfunktionen , wie Font, Linien, Rechtecke, Abgerundete Rechtecke, Texturen machen wil, dann einfach die inc file auswechseln.
Das gleiche gilt übrigens für canvas cpu und alles der TDGL_AppWindow. Wenn man also unter Windows/Linux GTK, QT, WinAPI, XLib,... verwenden will, dann wechselt man einfach die dglwindow.inc aus.

Dieses System hat den Vorteil, das man in einem extra svn Ordner dann verschiedene versionen der inc files ablegen kann und der User dann einfach zwischen den include files wählt.

Ich hab die Widgets aus X-Dream übernommen, daher sind die Stabiler und haben weniger Kinderkrankheiten.
Es gab auch fixes und neue Widgets, wie z.b. Tabsheets.

Edit: Ich hab mal ein Commit meiner letzten änderungen gemacht.

Da ich seit einigen Tagen mit Java und dingen wie Swing zu tun hab, hab ich etwas sehr nützliches in Swing kennen gelernt.
Unzwar Border. Man kann jeden Element ein Border zuweisen und dann diesem eine Farbe geben.
Somit kann man sehr gut bei der Entwicklung von GUI und Widgets debuggen.
Es gibt auch ein Feature, welches am Cursor Infos über Position ausgibt.

Ich denke, es könnte recht nützlich sein, als Debug Modul TDGL_Border und TDGL_CursorText zu bauen.

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

Projekte: https://github.com/tak2004

Oder, anders und viel kürzer ausgedrückt: wir sind noch nicht fertig, Jonas. Ich meine, dass man jetzt mit der Schnittstelle noch zu früh dran ist. Sonst müssen wirs dann machen wie Microsoft: gleich nach der Beta das erste Servicepaket.

EDIT:
Und ich habe bemerkt, dass die Leute nicht mehr wissen, was genau wir hier eigentlich tun. Und wenn ich ehrlich bin: ich kanns Euch nicht verdenken. Seit der Beschreibung im Wiki hat sich das Konzept wesentlich weiterentwickelt.

Das Konzept ist es wert, einmal ganz genau und detailliert beschrieben zu werden. Aber man kann es nicht in einem Beitrag beschreiben. Ja, ich weiß, ich müsste mich mal hinsetzen und eine genauere Beschreibung des Grundkonzepts erstellen (ICH bin hier der Schreiberling).

Ich hatte sogar mal mit dem Gedanken gespielt, die Beschreibung in Form eines Comics zu machen - die einzige Möglichkeit, zu gewährleisten, dass die Leute es WIRKLICH lesen. Aber: ich habe im Augenblick keine Zeit dazu.

Bitte versteh, dass wir erst einen bestimmten Level "erklimmen" möchten, bevor ich an eine Beschreibung denke. Und ich glaube, wir erweisen der Sache keinen guten Dienst, zu früh mit einem Zwischenergebnis herauszukommen, weil sich manchmal Grundlagen noch ändern.