Diesen Thread hab ich wegen folgenden Gründen ins Leben gerufen.
Es kommt sehr häufig vor, dass man mal eine GUI in einer Demo oder Spiel braucht und nicht gerade eine selber schreiben will.
Für eine gute GUI braucht man aber ein gut durchdachtes Konzept und man muss wissen was gebraucht wird.

In Laufe der Diskussion mit Traude(TinyGUI) sowie I0n0s und mir(XD_GUI) hat sich ein gemeinsames Ziel geformt.
Wir wollen eine GUI haben die jeder nutzen kann und sich somit viel arbeit erspart.
XD_GUI ist schon etwas älter und hat viele Fixes gehabt und bekommt sie immer wieder aber es sind einige Dinge nicht eingeplant gewesen.

Ich habe viele gesehen die GUI angefangen haben und wenige die am ende auch was raus hatten.
Für eine gut genutze GUI muss also fest gestellt werden, was sie können muss.
Dieser Thread soll mit Hilfe von Brainstorming dies erziehlen.

Wie soll das ablaufen ?
Für ein gutes Ergebnis hab ich folgende Regeln.
1) Man schlägt eine Idee vor und erzählt kurz was dazu.
2) Die vorgeschlagenden Ideen werden kurz Diskutiert und dann eventuell in die Facts aufgenommen.
3) Die Facts, im erstem Post, zeigen was aus dem Brainstorming raus gefiltert wurde und akzeptiert wurde.


Facts:
-alle benötigten Funktionen(ausser die in de RTL enthalten sind) müssen über eine Unit mit aussenstehenden Code verbunden/gewrappt werden
-XML support für das speichern von Formulardesigns
-Theme support
-Fallback von Theme auf normale Zeichenroutinen
-Events werden vom programmierer code aufgerufen
-es gibt ein Manager der die GUI verwaltet
-Scriptanbindung zur erstellung und manipulation der GUI
-alle Komponenten werden von einer Grundkomponente abgeleitet

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

Projekte: https://github.com/tak2004

Vorschlag:
Alle benötigten Funktionen(ausser die in de RTL enthalten sind) müssen über eine Unit mit aussenstehenden Code verbunden/gewrappt werden.

Beschreibung:
Alle Funktionen wie z.B. zeichnen, laden von Fonts und Images, Zeichenbereich,... sollen über ein nach innen Einheitliches und nach aussen frei änderbares Funktionspaket verfügbar gemacht werden.

Vorteile:
-man ist unabhängig von APIs
-erhöht die Lesbarkeit des Codes
-bei Bugs in den Funktionen muss nicht der Code von jeder Komponente angefasst werden

Nachteile:
-1 Funktionscall mehr(geringe mehrbelastung)


Vorschlag:
XML support für das speichern von Formulardesigns.

Beschreibung:
Man soll in einer XML Datei Informationen über ein Formular speichern/laden können.

Vorteile:
-Programmcode,zur erstellung von Formularen, verringert sich
-Möglichkeit für Mods

Nachteile:
-höhere Ladezeiten


Vorschlag:
Scriptanbindung zur erstellung und manipulation der GUI.

Beschreibung:
Man soll die Möglichkeit haben eine Scriptsprache an die GUI zu hängen, um dann die GUI zu verarbeiten, manipulieren und Laden zu können.

Vorteile:
-in verbindung mit XML Formularen wird die Content erstellung ohne Prorammierer und compiler möglich
-Code ersparnis
-flexibel

Nachteile:
-langsamer als Programmcode
-man muss eine Scriptsprache erlernen


Vorschlag:
Es gibt ein Manager der die GUI verwaltet.

Beschreibung:
Eine Managerklasse soll die Widgets verwalten und Funktionen für die manipulierung der Zeichenreihenfolge, zeichnen der GUI und die Events weiter leiten.

Vorteil:
-übersichtlichere Struktur des Codes
-vereinfachung für die programmierung der GUI

Nachteil:
?


Vorschlag:
Events werden vom programmierer code aufgerufen.

Beschreibung:
Der Programmierer soll die Vorhandenen Events in der GUI aufrufen.

Vorteil:
-bessere Event Kontrolle
-unabhängig von System Messages

Nachteil:
-System Messages müssen ausgewertet werden und entsprechend den GUI Events angepasst werden


Vorschlag:
Theme support.

Beschreibung:
Der Theme support soll erlauben Komponenten mit Bildern zu versehen und einstellungen wie Ränder, Farben und Schriftgröße zu manipulieren.

Vorteil:
-bessere Designs möglich
-ermöglicht einfacheres Customizing

Nachteil:
?


Vorschlag:
Fallback von Theme auf normale Zeichenroutinen.

Beschreibung:
Wenn im Theme keine Info zu einer Komponente zu finden ist, dann soll die Zeichenroutine ein Fallback auf die normale Zeichenroutine(ohne Bilder) machen.

Vorteil:
-Fehler werden vermieden
-aufwärtskompatibel

Nachteil:
?

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

Projekte: https://github.com/tak2004

Das würde hoffentlich nur die Grundfunktionen einschließen, spezialisierungen sollten über die Polymorphy realisiert werden. Der Functioncall bleibt damit trozdem noch bei -1


Um den Nachteil zu verringern, könnte man das XML GUI in ein binäres Format speichern, damit dürfte sich die Performance wesentlich erhöhen.

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

Beim binären Format verliert man aber den Vorteil der Editierbarkeit ausserhalb der Anwendungen.

Und das mit dem Polymorphy müsstest du mir mal erklären

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

@Binärformat: Wieso verliert man die editierbarkeit? Der "Nutzer" hat am GUI nichts zu manipulieren. Und der Entwickler verfügt doch über die XML Dateien. Die müssten halt nach jeder Änderung in das binärformat geschrieben werden.

@Polymorphy: Ganz einfach. Man erstelle eine abstrakte Klasse und leitet von diese dann die konkreten Klassen ab. Alles was man dann noch braucht ist eine entsprechende Loader Klasse bzw Funktion die den Job übernimmt. In der COnfig Datei würde man dann die spezifische Klasse die instanziert werden soll definieren und würde fortan die Methoden selbiger nutzen, durch die Polymorphy aber gleichzeitig nicht die Grundfunktionalität der Basisklasse verlieren.

Ist prinzipiell nichts anderes als Dependicy Injection.

Man kann das ganze halt mit abstrakten Klassen und oder Interfaces machen. Bei Interfaces wird dann allerdings entsprechend nur die Funktionssignatur vorgegeben. Das Interface hätte dafür den Vorteil das man eine vorher inkompatible Klasse durch die Signaturen des Interfaces kompatibel mit der zugrunde liegenden API machen könnte. Hoffe das war soweit verständlich.

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

Da kann ich nur sagen: Mahlzeit!

Worauf läufts hinaus: auf eine echte plattformunabhängige GUI mit OpenGl für Pascal.
Was wird gebraucht:
1. Compiler: muss eine Pascal Unit einbinden können (z.B. Delphi oder Free Pascal)
2. Für die Zeichenroutinen: OpenGL
3. Fürs Texturen laden ein Texturenmanager(muss den Vorgaben der GUI genügen)
4. Fürs Schreiben ein Fontmanager(muss den Vorgaben der GUI genügen)

Damit wir uns recht verstehen: Texturenmanager und Fontmanager sind NICHT in der GUI inkludiert.

Kommentare zu Taks Vorschlägen:


Genau.


Da bin ich zwar nicht so begeistert, weil ich mit xml nicht so gut kann und außerdem, weil ich dafür ja noch eine weitere Library benutzen muss. Aber xml ist ein Standard, und daher ebenfalls einverstanden.


Für ein Spiel - und dafür ist es natürlich gedacht - unbedingt nötig. Einverstanden. Noch eine Library (Seufz).


Ja.


Ja. Das garantiert Library-Unabhängikeit.


Einverstanden. Ist ja wohl auch Standard. (Puh, da werd' ich ganz schön ins Schwitzen kommen, aber brauche wenigstens keine neue Libray)


Das halte ich für vernünftig.


Eigener Vorschlag:
Ich habe geplant, die Elemente nicht auf 2D zu beschränken, sondern von Grund auf in 3D zu machen, mit der Möglichkeit, kompliziertere Objekte (GUI-Items) zu laden.
Das bedeutet, dass ein 3D-Objekt eingebaut ist (auch zur freien Verwendung für den Benutzer).
Ich habe geplant, das Projekt unter die LGPL zu stellen, also vollkommen frei (Hehe, das kein Wahlverspechen und ich habe auch nicht die Finger hinter dem Rücken gekreuzt).

Ich habe ein wesentliches Eigeninteresse daran, ein solches Programm zu erstellen: ich werde in Zukunft von Delphi auf Free Pascal wechseln. Und es wird Zeit für mich, Linux-Luft zu schnuppern. Aber dort, in dieser Linux-Welt, ist die Auswahl von in Frage kommenden GUIs nicht besonders groß. Soll heißen, ich habe keine für mich passende gefunden. Aber: ich möchte das Rad nicht gänzlich neu erfinden. Das Benutzen von Libraries birgt Risiken, aber auch große Chancen. Ich glaube zwar, dass man sich auf möglichst wenige Libraries beschränken sollte - je weniger desto besser - aber es wäre ein Fehler, ganz darauf zu verzichten. Es gibt übrigens eine in SDL eingebaute GUI, hat das schon jemand zur Kenntnis genommen?

Ich würde die Programmierung übernehmen (außer es drängt sich jemand vor, dann mache ich gerne Platz ). Ich bräuchte dann aber ein wenig Unterstützung, und zwar bei

- xml (hier kann ich allerdings auch auf gute Literatur zurückgreifen) und
- Scriptanbindung

Das andere meine ich wohl alleine schaffen zu können. Das heißt natürlich nicht, dass mir nicht jede Hilfe willkommen wäre.

Ich möchte folgendermassen vorgehen: Ich werde ein Konzept schreiben, unter Einhaltung aller Vorgaben, über die wir uns einigen können. BEVOR ich auch nur eine einzige Codezeile schreibe, muss ein "Weißbuch" existieren (Keine Angst, das schreibe ich schon selbst. Aber ich werde es Euch zur Begutachtung vorlegen).

Traude

Wieso willst du von Grund auf ein GUI Objekt als 3D Objekt deklarieren? Oder wie hat man sich das vorzustellen? Denn sobald jemand keine 3D Objekte nutzen will, kann er mit der GUI nichts mehr anfangen. Je nachdem was für gemeinsame Eigenschaften ein 2D und 3D Objekt haben, sollte man auch hier den entsprechenden OOP Ansatz verfolgen.

@XML: Solange ihr nicht genötigt seit eine DTD zu schreiben ist XML sehr einfach. Mit einer DTD ist man bei einem entsprechenden Valdierungsparser halt auf der sicheren Seite wenn es darum geht zu checken ob der Entwickler die XML Datei konform gestaltet hat.

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

Das ist einfach. Der Benutzer sagt AddButton(.......) oder der Button ist vordefiniert und wird per XML bereits geladen, dann braucht der Benutzer gar nichts zu tun. Wie die GUI ihren Knopf darstellt, ist ja ihre Sache. Der User muss das 3D nicht benutzen. Aber er KANN.
Traude

@edit: 2D ist eine Teilmenge von 3D

Deswegen weiß "ich" trotzdem nicht was du dir unter einem 3D Button vorstellst. Ich für mich kann mir unter dem Begriff 3D GUI nur plastische Elemente vorstellen. Dies Forum hier ist trotz seiner Farbakzente zb. 2D

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

Das verstehe ich nicht. Ich lerne hier seit einem Jahr. Mit dem Wissen aus dieser Community habe ich eine 3D-Modeller geschrieben (mein Blechkopf-Avatar war mein erstes Werk) - meines Erachtens ist das kein 2D-Forum.
Traude

Lern lesen! Ich hab nicht gesagt das dies hier ein 2D Forum ist sondern das dies Forum als solches nur 2D ist. Oder siehst du hier 3D GUI Elemente?

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

Ein Button ist übrigens per Definitionem 3D. Auch Windows stellt einen Button so dar dass er aussieht, als wäre er 3D, aber es ist nur eine Täuschung des Betrachters. Solche Täuschungen können auf mannifaltige Weise implementiert werden, auch als (rein mathematisches) 3D-Element. Die GPU verrechnet das Zeug ja sowieso wieder und patscht es auf 2D zusammen. Es kommt also bloss auf die Täuschung des Betrachters an. Und das kann man erzeugen, wie man will.

Dieses Feature ist für den Normalgebrauch nicht interessant, zugegeben. Aber für Spiele? ein 3D-Spiel möchte vielleicht auch in der GUI einen 3D Effekt einbringen. Warum soll ich mir das von Anfang an verbauen? Wir sind heutzutage so sehr an die Windows-Oberfläche gewöhnt, dass wir uns gar nichts anderes mehr vorstellen können. Ich kann ja auch einen 3D Button zeichnen, KEINE Textur einbinden und in OpenGL einfach das Licht anknipsen.

'Tschuldigung habe Dich falsch verstanden.
Natürlich ist hier alles flach, ist ja auch ein Forum, da befinden wir uns im Flachland. Aber ich schreibe dies gerade im Bereich, wo man eben die Beiträge verfasst und und hier gibt es Steuerelemente, die - weil sie eben wie Windowsknöpfe aussehen - schaun fatal nach 3D aus.

Ja, sie sehen aus wie 3D, aber sind es nicht. Perse wäre das auch nur eine 2D Textur. Irgendwo hatte ich mal ne App gesehen die coole 3D Buttons verwendete. Die konnte man so schaukeln lassen etc. Das stell ich mir unter 3D Buttons vor. Alles andere was nur eine Textur zum Erzeugen einer 3D Illusion nutzt ist für mich 2D. Es seidenn du möchtest Geometrie Shader einsetzen

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

Du überschätzt mich ^^. Alles was ich gerne möchte ist zumindest den Anschluss nicht verlieren. Das könnte man z.B. gewähleisten durch einen guten Programmaufbau. Selbst wenn man in einer Programmsektion zunächst einmal nicht den optimalen Code hat, ist es dann möglich, durch Ersetzen von nur dieses Programmteils mit modernerem Code das ganze Ding aufzuwerten. Es ist mir bewusst, dass man das nie wirklich schaffen kann. Ich habe z.B. ein interessantes Ding gefunden, während meiner GUI-Recherche, nennt sich Graphix und ist für Free Pascal und augenscheinlich für DOS geschrieben worden. Einige Features waren wirklich gut - er hat z.B. jpg selbst geladen. Das ist nicht leicht. Aber jetzt will es natürlich niemand mehr. Alle Dinge haben einen Lebenszyklus und irgendwann sterben sie ab, auch wenn sie gut waren.