Grundsatzduskussion: GUI Implementation

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	bruZard Betreff: Grundsatzduskussion: GUI Implementation	Sa, Jun 18, 2005 13:57 Antworten mit Zitat
Eines gleich vorweg: Es geht hier tatsächlich nur um Ideen für Ansätze und rudimentäre Ideen. Es geht mir keineswegs darum fertige Codes zu "klauen" oder zu "kopieren". Da ich der Thread-Ersteller bin fange ich mal mit meinem Grundsatz an und würde mich freuen wenn Ihr diesen total auseinander nehmt, ihn zerpfückt und bessere Ideen habt. -------------------------------- Meine Grundidee ist die: Der Benutzer soll nicht merken dass hinter seinen Funktionen die er benutzt um eine Oberfläche zu erzeugen ein komplexes OOP Modell steht und alles "irgendwie" miteinander verbunden ist. D.h. dass die komplette Klassenstruktur durch Wrapperfunktionen bedient wird und es niemals notwendig wird direkt über ein (bspw.) Code: [AUSKLAPPEN] [EINKLAPPEN] Local window_width = tools_window:TTMGUI_Window.width auf Werte oder Methoden der Klasse zuzugreifen. 1. In meinem Ansatz wird jedes GUI Element von der Basis-Klasse "TTMGUI_Area" abgeleitet. Diese Klasse hat nur rudimentäre Eigenschaften und keine Funktionen oder Methoden (es ist imho in BMax unnötig virtuelle Methoden zu definieren). 2. Jedes Element hat seine eigene Update- und Draw-Methode. Das ist zwar im Endeffekt ein erheblicher Mehraufwand was das tippen von Code betrifft, erlaubt aber das jedes Element individuell auf seine eigenen Erfordernisse reagieren kann und nicht von globalen "Verhaltensmustern" abhängig ist. 3. Es gibt keinen Event-Stack. So ein Stack würde die Grundidee der wahnsinnig einfachen Benutzung zunichte machen da der User gezwungen ist sich in ein Stack-System einzudenken und es vorkommt dass Ereignisse in der Pipe liegen auf die er nicht reagieren möchte und man so Nebeneffekte erzeugt die im schlimmsten Fall zu einem Absturz der App führen wegen eines simplen Overflows. Ich würde es eher so implementieren dass der User nur ein globales Event zurück bekommt und dieses in einem SELECT Konstrukt prüft. Direkt nach der Rückgabe des Events ist dieses ungültig. Falls das Ereignis trotzdem länger überleben soll wird es auf den aktuellen State des Elements gelegt der dieses Event zurück gegeben hat. 4. Alles hat einen Defaultwert. Gibt es keinen Skin wird nach einem Defaultskin gesucht, existiert der auch nicht wird ein Skin mit den Standard-Zeichenfunktionen gemalt. Jeder Parameter einer jeden Funktion ist optional. In einem Developer-Stack wird bei wahnsinnig wichtigen Parametern eingetragen dass es doch schön wäre wenn der user sich hier was ausdenken könnte. Wird die App im Debug ausgeführt wird beim beenden ein Debug-Log als Textdatei in den Projektbereich des users geschrieben. So, bis hier her und [erst mal] nicht weiter. Was muss noch alles bedacht werden? Was würdet Ihr anders machen? Wo liegen essentielle Denkfehler? Wie gesagt: Dies hier ist eine Grundsatzdiskussion und das Ziel ist es die neuen Möglichkeiten von BMax optimal zu nutzen und von den Erfahrungen und dem Wissen aller anderen Diskussionsteilnehmer zu profitieren.
PIV 2,4GHz - 1GB DDR 333 - ATI Radeon9600 - WinXP - DX9.0c - BMax 1.14 - B3D 1.91 - 1280x1024x32 User posted image

bruZard

Betreff: Grundsatzduskussion: GUI Implementation

Sa, Jun 18, 2005 13:57
Antworten mit Zitat

Eines gleich vorweg: Es geht hier tatsächlich nur um Ideen für Ansätze und rudimentäre Ideen. Es geht mir keineswegs darum fertige Codes zu "klauen" oder zu "kopieren".

Da ich der Thread-Ersteller bin fange ich mal mit meinem Grundsatz an und würde mich freuen wenn Ihr diesen total auseinander nehmt, ihn zerpfückt und bessere Ideen habt.

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

Meine Grundidee ist die: Der Benutzer soll nicht merken dass hinter seinen Funktionen die er benutzt um eine Oberfläche zu erzeugen ein komplexes OOP Modell steht und alles "irgendwie" miteinander verbunden ist.
D.h. dass die komplette Klassenstruktur durch Wrapperfunktionen bedient wird und es niemals notwendig wird direkt über ein (bspw.) Code: [AUSKLAPPEN]

Local window_width = tools_window:TTMGUI_Window.width

auf Werte oder Methoden der Klasse zuzugreifen.

1. In meinem Ansatz wird jedes GUI Element von der Basis-Klasse "TTMGUI_Area" abgeleitet. Diese Klasse hat nur rudimentäre Eigenschaften und keine Funktionen oder Methoden (es ist imho in BMax unnötig virtuelle Methoden zu definieren).
2. Jedes Element hat seine eigene Update- und Draw-Methode. Das ist zwar im Endeffekt ein erheblicher Mehraufwand was das tippen von Code betrifft, erlaubt aber das jedes Element individuell auf seine eigenen Erfordernisse reagieren kann und nicht von globalen "Verhaltensmustern" abhängig ist.
3. Es gibt keinen Event-Stack. So ein Stack würde die Grundidee der wahnsinnig einfachen Benutzung zunichte machen da der User gezwungen ist sich in ein Stack-System einzudenken und es vorkommt dass Ereignisse in der Pipe liegen auf die er nicht reagieren möchte und man so Nebeneffekte erzeugt die im schlimmsten Fall zu einem Absturz der App führen wegen eines simplen Overflows.
Ich würde es eher so implementieren dass der User nur ein globales Event zurück bekommt und dieses in einem SELECT Konstrukt prüft. Direkt nach der Rückgabe des Events ist dieses ungültig.
Falls das Ereignis trotzdem länger überleben soll wird es auf den aktuellen State des Elements gelegt der dieses Event zurück gegeben hat.
4. Alles hat einen Defaultwert. Gibt es keinen Skin wird nach einem Defaultskin gesucht, existiert der auch nicht wird ein Skin mit den Standard-Zeichenfunktionen gemalt. Jeder Parameter einer jeden Funktion ist optional. In einem Developer-Stack wird bei wahnsinnig wichtigen Parametern eingetragen dass es doch schön wäre wenn der user sich hier was ausdenken könnte. Wird die App im Debug ausgeführt wird beim beenden ein Debug-Log als Textdatei in den Projektbereich des users geschrieben.

So, bis hier her und [erst mal] nicht weiter.

Was muss noch alles bedacht werden? Was würdet Ihr anders machen? Wo liegen essentielle Denkfehler?

Wie gesagt: Dies hier ist eine Grundsatzdiskussion und das Ziel ist es die neuen Möglichkeiten von BMax optimal zu nutzen und von den Erfahrungen und dem Wissen aller anderen Diskussionsteilnehmer zu profitieren.

PIV 2,4GHz - 1GB DDR 333 - ATI Radeon9600 - WinXP - DX9.0c - BMax 1.14 - B3D 1.91 - 1280x1024x32

User posted image

	Dreamora	Sa, Jun 18, 2005 17:07 Antworten mit Zitat
3. Meinst du nicht eventuell eine Event-Queue, da ein Stack die Eventreihenfolge umdreht? Ansonsten erscheint mir das Verhalten so, wie es sein sollte. Ein abgerufenes Event ist weg ... sollte man es aus irgend einem Grund später noch brauchen kann man es bei der Verarbeitung nochmal "feuern" Einer der elementaren Vorteile von BM geht aktuell dabei leider unter: Funktionspointer. Damit könnte der User direkt Eventhandlingfunktionen an die Objekte übergeben, die beim Auftreten eines Events ausgeführt werden anstatt den Event in die Queue zu packen, damit er nochmal verarbeitet werden muss. Dann würden einige der Events garnicht erst entstehen (speziell alles was man anklicken kann)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Sa, Jun 18, 2005 17:07
Antworten mit Zitat

3. Meinst du nicht eventuell eine Event-Queue, da ein Stack die Eventreihenfolge umdreht?
Ansonsten erscheint mir das Verhalten so, wie es sein sollte. Ein abgerufenes Event ist weg ... sollte man es aus irgend einem Grund später noch brauchen kann man es bei der Verarbeitung nochmal "feuern"

Einer der elementaren Vorteile von BM geht aktuell dabei leider unter: Funktionspointer.

Damit könnte der User direkt Eventhandlingfunktionen an die Objekte übergeben, die beim Auftreten eines Events ausgeführt werden anstatt den Event in die Queue zu packen, damit er nochmal verarbeitet werden muss. Dann würden einige der Events garnicht erst entstehen (speziell alles was man anklicken kann)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Nemesis	Sa, Jun 18, 2005 17:26 Antworten mit Zitat
Ich würdedie Event's auch mit callback functionen realisieren. Was meinst du mit Wrapperfunctionen? Wenn du setter und Getter meinst wäre ich auch jedenfall dafür.

Nemesis

Sa, Jun 18, 2005 17:26
Antworten mit Zitat

Ich würdedie Event's auch mit callback functionen realisieren.
Was meinst du mit Wrapperfunctionen? Wenn du setter und Getter meinst wäre ich auch jedenfall dafür.

	bruZard	Mo, Jun 20, 2005 9:28 Antworten mit Zitat
CallBacks an Events zu hängen kann man als "nice to have" deklarieren, im Standardfall würde ich ein Select ... Case ... EndSelect vorgeben. Die "Update()" Funktion gibt halt einen Wert zurück und der User regiert im entsprechenden "Case" darauf. Als Rückgabewerte von Create() Funktionen habe ich das Objekt selbst erkoren. Beispiel: Code: [AUSKLAPPEN] [EINKLAPPEN] my_window:TTMGUI_Window = NewWindow(0,0,320,200,"Hallo Welt") Mittels "Return Self" gibt die "Create-Methode" des Types sich selbst zurück und man hat somit eine wunderbare Möglichkeit die Objekte an das Interface zu übergeben ohne jedes Type global definieren zu müssen.
PIV 2,4GHz - 1GB DDR 333 - ATI Radeon9600 - WinXP - DX9.0c - BMax 1.14 - B3D 1.91 - 1280x1024x32 User posted image

bruZard

Mo, Jun 20, 2005 9:28
Antworten mit Zitat

CallBacks an Events zu hängen kann man als "nice to have" deklarieren, im Standardfall würde ich ein Select ... Case ... EndSelect vorgeben. Die "Update()" Funktion gibt halt einen Wert zurück und der User regiert im entsprechenden "Case" darauf.

Als Rückgabewerte von Create() Funktionen habe ich das Objekt selbst erkoren. Beispiel:
Code: [AUSKLAPPEN]

my_window:TTMGUI_Window = NewWindow(0,0,320,200,"Hallo Welt")

Mittels "Return Self" gibt die "Create-Methode" des Types sich selbst zurück und man hat somit eine wunderbare Möglichkeit die Objekte an das Interface zu übergeben ohne jedes Type global definieren zu müssen.

PIV 2,4GHz - 1GB DDR 333 - ATI Radeon9600 - WinXP - DX9.0c - BMax 1.14 - B3D 1.91 - 1280x1024x32

User posted image

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Grundsatzduskussion: GUI Implementation

bruZard

Betreff: Grundsatzduskussion: GUI Implementation

Dreamora

Nemesis

bruZard