Ich überarbeite momentan die GUI von X-Dream und eine der änderungen ist die unabhängigleit.
Die Version ist momentan noch nicht fertig und ist auch nicht im X-Dream Repo zu finden.
Momentan entferne ich alle abhängigkeiten ausser von XD_Singleton und standard units, die mit Delphi und FPC mit kommen(sysutils,classes,math).
Es ist auch keine abhängigkeit mehr von dglopengl vorhanden.
Ich habe eine Unit geschrieben namens xdwrap_gui.pas, welche alle notwendigen funktionen durchschleift.
Sprich man hat ein zur GUI hin einheitliches funktionspaket(DrawBox,DrawFont,...) und zur anderen Seite ist sie offen gelassen.
Also wenn man die GUI auf z.B. SDL benutzten will, dann schreibst man nur den notwendigen code in die funktionen und fertig.
Somit ist es möglich die GUI mit Opengl, SDL, Windows, Linux filedevices(fb) und so weiter zu nutzen(neben den Softwaregrenzen fallen auch Hardwaregrenzen weg).
Die anpassung hat aber noch ein paar weitere Punkte, z.B. kommt endlich ein Thememanager hinzu.
Eine Scriptanbindung ist momentan nur für Lua speziel realisiert und XD_GUIXML soll noch ein Designer Tool erhalten.
Momentan sind noch abhängigkeiten zu Lua und bei nutzung von XD_GUIXML noch libxmlparser vorhanden.
Es gibt eine neue Klasse namens TXD_Canvas2D, wo alle wrapper funktionen ihren Platz finden.
Ausserdem wird über diese Klasse der default zeichenmodus realisiert. Dieser sieht wie der Win2k Fenstersystem aus.
In meiner X-Dream Implementierung läuft die GUI über OpenGL,SDL und SDL_TTF.
Ich will auch noch eine reine SDL variante machen, um die auf mein GP2X zu nutzen.

Hilfe, Anregungen, Ideen und so weiter sind erwünscht.

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

Projekte: https://github.com/tak2004

Ne gute Idee für ein Skinsystem wäre vom Vorteil, mit dem aktuellen Ansatz kann man zwar den Skin ändern, denoch ist es sehr kompliziert einen neuen Skin für die GUI zu entwerfen.
Hier wäre eine Idee, wie man sowas am besten löst vom Vorteil.

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

Viele Komponenten laufen nun schon so wie sie sollen und haben noch einiges an bugfixes mit sich gebracht.
Die alte version der GUI hatte ab und zu falsche Formeln für die Darstellung oder events.
Momentan hab ich folgende Komponenten fertig:
-Window
-Panel
-Editbox(korrektur und erweiterung der selektion)
-Button(erinnert an die TSpeedButton version)
-ComboBox(korrektur und verbesserung der funktionalität)
Nun kommen noch
-Label
-CheckBox
-RadioBox
-List
-TreeList(existiert noch nicht)
-Table(existiert noch nicht)

Das Skinsystem wird ähnlich dem von Metacity, nur fallen einige Teile wie DrawOps weg.
Man kann die Farben festlegen und sagen, dass für bestimmte Teile einer Kompo Grafikdatein genutzt werden sollen.
Das wird alles in einer XML file passieren und der Loader ist auch schon fertig.
Sind keine Image Datein angegeben, dann weicht die GUI auf eigene Zeichenroutinen aus.

Die arbeit schleift momentan ein bischen, da ich seit Fr ununterbrochen Gothic3 spiele .
Allerdings find ich auch mal pausen zwischendurch und in den arbeite ich dran weiter.

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

Projekte: https://github.com/tak2004

da ich auch an einer GUI dran bin atm, würde mich interessieren, wie du das machst mit den grafiken. Ob du da das ganze aus einer grossen Textur lädst oder eben aus zig kleinen.

mfg

_________________
bester uo-shard: www.uosigena.de

Aktuell aus mehreren kleinen Texturen. Ansich hatte ich vor, dass Frases Texman dann die Texturen vereinigt und auch abspeichert, das beisst sich aber mit TAKs Konzept.
Achso, ne Kleinigkeit: Ich verwende natürlich Texturen doppelt, nicht jede Komponenten hat eine eigene Textur. Das Editfeld benutzt dieselbe Textur wie das Panel.

Aber wenn jetzt soviele Leute an GUIs arbeiten:
Könnten wir nicht die Funktionen für KeyPress, MouseMove, MousePress veröffentlichen?
Weil die sind die Monster bei der GUI, zumindest wenn man z.B. ein Memo nachprogrammiert.
Was haltet ihr (Gaukler, Lossy und Flash) davon?

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

Ich denke mal das hängt ganz davon ab wie die Texturen aussehen bzw wie es im Skin festgelegt ist. Aber generell empfielt es sich eher eine große Textur zu benutzen. Um Texturwechsel zu vermeiden. Was aber eigentlich auch quatsch ist, da fast alle Komponenten nun schließlich auch Fonts haben und das befindet sich eh auch in einer anderen Textur. Und dann ist man wieder da, dass man ständig zwischen 2 Texturen hin und herwechseln muss. Also das Optimum wäre eigentlich, wenn alle Daten in einer Textur vereint wären. Allerdings denke ich nicht, dass sich das so extrem bemerkbar machen wird, wenn das nicht der Fall wäre.

i0n0s: Also vom Prinzip habe ich nichts dagegen code zu teilen. Allerdings ist das derzeit meine 2te GUI bzw mein zweites design. Vorher habe ich es bewusst zu klein gehalten wodurch ich mir allerdings irreparable Schwächen eingefangen habe. Und mittlerweile weiß ich ziemlich genau was ich will und das ist vor allem ziemlich verwirrend. Derzeit bin ich aber auch noch hauptsächlich mit dem Handling um allem herum beschäftigt als mit dem implementieren konkreter Komponenten. Bzw muss ich persönlich erst einmal eine sinnvolle Fontunterstützung implementieren.

Memos hatte ich allerdings in den vorherigen Komponenten auch noch nicht gemacht. Aber ich denke auch mal, dass sich die Codes nicht ohne Probleme in die entsprechenden Strukturen übernehmen lassen. Jeder hat ein anderes Design gewählt und dadurch ist es intern auch komplett anders aufgebaut. Ich denke, dass man da auf jeden Fall vorsichtig sein sollte.

PS: Lädst du die Texturen auch doppelt in den Speicher?

Da die X-Dream GUI ja so konzipiert ist, ohne texturmanager und so weiter zu kommen, ist sowas nun ziemlich blöd zu definieren.
Wenn man von der X-Dream GUI mit X-Dream Modulen ausgeht, dann Lädt der Texturmanager alle Texturen und bei jedem weiteren Versuch eine Textur zu laden wird die schon geladene Textur zurück gegeben. Halt Singleton like("Es kann nur einen geben!").

Die GUI hat einen Manager und in diesem sind Events als functionen/proceduren zu finden.
Wenn man also nun ein Event auslösen will, dann ruft man die funktion/procedure mit entsprechenden Parametern auf und sie wird durch die Widgets gereicht.
Somit kann man selber bestimmen ob die Messages von Win,Linux,SDL,... API kommen sollen oder vieleicht durch ein Script oder ähnliches aufgerufen wird.
Als Schnittstelle für Grafisches hab ich eine Klasse TXD_Canvas2D geschrieben, welche alle funktionen für zeichnen von Fonts,Texturen,Boxen,ShadedBoxen,... oder auch funktionen wie getwidth für Text. Wenn man nun eine Texturmanager oder FontManager oder ähnliches hat kann man dann einfach die funktionen des Managers in die Funktionen von TXD_Canvas2D schreiben.

Alle Komponenten die ich bisher eingebunden hab verhalten sich fast wie von Windows bekannt.
Einziges Problem sind die Fonts, denn sie sind nicht ganz sauber gezeichnet.
Der Titel in einem Fenster z.B. sieht noch im dunkelblauen Bereich gut aus aber im hellblauen sieht man dann an einigen Stellen Ränder um die Fonts.

Was noch wenig beachtung bekommen hat, ist das ansteuern von Komponenten via Keyboard.
So funktioniert der Fokuswechsel per Tab oder das auslösen per Space noch nicht aber ich werde auch dieses noch implementieren.

Der X-Dream Code ist ja sowieso immer offen und im X-Dream Repo zu finden.

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

Projekte: https://github.com/tak2004

Zu der Font:
Ändere mal die Rendermethode auf Quick&Dirty, dann wird nur geblendet.
Bei den anderen Methoden wird erst per Alphatest mit Schwarz "vorgestanzt" damit die Farbe beim Blenden nicht verändert wird.
Ist halt die Kombination aus Alphatest, wo die Schrift "verpixelt" ist, und Blending, wo man die Farben vergessen kann.

Als Alternative zum Umstellen der Rendermethode könntest du aber auch versuchen den Wert für den Alphatest anzupassen.

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

Ich hatte schon den Rendermode geändert doch fällt ja im Quick and Dirty Mode alle abstufungen von farben weg.
Sprich Schwarz, Grau sind nicht mehr sichtbar.
Ich lege erstmal eine Gothic3 Pause ein und werde nun versuchen noch einige Komponenten zu realisieren.

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

Projekte: https://github.com/tak2004