Algierlib: GUI Bibliothek

Th69

Hallo Artchi,

das Design gefällt mir schon ganz gut, insbesondere die strikte Trennung zwischen GUI-Elementen und Daten.

Einige Fragen habe ich aber zur Windows-Klasse: kann man einzelne Elemente auch wieder aus einem Fenster entfernen, da ich nur eine attach()-Funktion, aber keine detach()-Funktion gesehen habe? Und kann man über alle Elemente iterieren?

Und zum Abschluß noch die Frage: soll auch irgendwann die Möglichkeit bestehen die Darstellung einzelner GUI-Elemente (Farbe, Farbverläufe, Hintergrundgrafiken etc.) anpassbar zu machen oder soll nur jeweils die native Darstellung benutzt werden können?

Artchi

Th69 schrieb:

Einige Fragen habe ich aber zur Windows-Klasse: kann man einzelne Elemente auch wieder aus einem Fenster entfernen, da ich nur eine attach()-Funktion, aber keine detach()-Funktion gesehen habe? Und kann man über alle Elemente iterieren?

Entfernen geht leider noch nicht, da ich das noch nicht in Angriff genommen habe. Ich muß ehrlich gesagt auch erstmal in der MSDN nach schauen, wie man HWND-Objekte löscht. Das fehlt noch im Dtor.

Aber danke für den Hinweis, habe mal Issues angelegt:
http://algierlib.tigris.org/issues/show_bug.cgi?id=59
http://algierlib.tigris.org/issues/show_bug.cgi?id=60

Th69 schrieb:

Und zum Abschluß noch die Frage: soll auch irgendwann die Möglichkeit bestehen die Darstellung einzelner GUI-Elemente (Farbe, Farbverläufe, Hintergrundgrafiken etc.) anpassbar zu machen oder soll nur jeweils die native Darstellung benutzt werden können?

Die nativen Win32-Controls kann man so gar nicht ändern. Müsste man aufwändig mit nem Owner Draw lösen. Da kenne ich mich aber nicht mit aus.

Ich kann mir aber vorstellen, das man später separate Klassen implementiert, die keine nativen Widgets nutzen (so wie es Gtk und Qt machen). So das man explizit als Programmierer die Klassen wählt. Aber daran denke ich zur Zeit nicht, da der Aufwand hier sehr hoch wäre. Oder es findet sich jemand, der das macht.

Th69

Lust hätte ich schon dazu, weiß jedoch nicht, woher ich die Zeit nehmen sollte.
Ich habe für das Spiel "Sacred 2" auch schon die 2D-GUI-Lib mitentwickelt (mit konsequenter Kapselung von Funktionalität und Design/Layout - die Windows konnten per XML serialisiert werden, so daß ich sogar einen (einfachen) InGame-WindowEditor entwickeln konnte). Diese beruhten zwar auf einem Renderer (inkl. Shaderprogrammierung), jedoch sollte das auch auf andere "Grafikengines" übertragbar sein (insbesondere wenn du nach X11 portieren willst, wirst du ja auch dann evtl. verschiedene Window-Layouts (Motif, Gnome, KDE (QT)) unterstützen wollen, oder)?

Zur Zeit programmiere ich beruflich auch überwiegend in C#, aber C++ läßt mich einfach nicht los -)
Wenn man etwas WPF ähnliches in C++ schaffen könnte, wäre das schon super...

Icematix

Ich finde das Projekt nett, die WinAPI ist im Gegensatz zu den meisten GUI Libs eben sehr "leicht"

Weiter so.

Artchi

@th69! WPF-artiges wäre für Algierlib keine Prio. WPF-artiges könnte für die Zukunft ein Thema sein. Es fehlen zu viele Basisfunktionen, wie du ja selber schon fest gestellt hast (detach, Iteration, editierbare Listen, Trees fehlen uvm.). Das Projekt hat auch keine Manpower, ich bin zur Zeit der einzige, der alles macht. Die Doku zu schreiben ist alleine schon sehr aufwändig.

Erstmal Danke an alle für das bisherige Feedback!

Blue-Tiger

Auf den ersten Blick gefaellts mir gut, bis auf die "_h" Suffixe fuer Handles. Ist zwar ein furchtbar subjektiver Punkt, aber fuer mich persoenlich sehr haesslich

Artchi schrieb:

Wie sieht die Zukunft aus?
Es ist ein Port auf X11-Systeme nötig, spricht X-Window. Somit UNIX-artige Systeme.

Aber wrap bitte GTK oder Qt, nicht Xlib direkt!

hustbaer

"_h" ist mir auch komisch vorgekommen.
Persönlich hätte ich eher "_handle" oder "_ptr" geschrieben. Ist aber nicht wichtig denke ich.

Was mich mehr verwirrt ist die ganze MVC Sache. Ich denke einzelne Buttons/... sind "zu klein", um damit vernünftig MVC zu machen. Ich denke dass es Dinge eher verkompliziert als vereinfacht. Andrerseits hab' ich auch noch nie mit so einem System gearbeitet, kann also auch nicht sicher sein ob es nicht in der Praxis total praktisch ist.

Artchi

Blue-Tiger schrieb:

Auf den ersten Blick gefaellts mir gut, bis auf die "_h" Suffixe fuer Handles. Ist zwar ein furchtbar subjektiver Punkt, aber fuer mich persoenlich sehr haesslich

Ja, aber was wäre denn das schönere? Ich fand es kurz zu schreiben und durch den Unterstrich hebt sich das "h" auch hervor. Wenn ich z.B. windowh (also ohne Unterstrich) machen würde, würde das "h" untergehen. Ist halt schwierig.

Aber solange es nur solche Kritikpunkte sind, kann ich mich also nicht beklagen.

Blue-Tiger schrieb:

Aber wrap bitte GTK oder Qt, nicht Xlib direkt!

Xlib sicherlich nicht. Ich habe da noch keine endgültige Entscheidung getroffen. Ich habe aber erstmal OpenMotif für einen Prototyp-Port vorgesehen. So kann ich sowohl die Gnome- als auch KDE-Fraktion nicht verärgern. OpenMotif ist eine stabile API. Das Look&Feel ist auch nicht mehr ganz so altbacken, da seit dem letzten Release UTF-8, PNG und Anti Aliasing Fonts unterstützt wird.

Artchi

hustbaer schrieb:

"_h" ist mir auch komisch vorgekommen.
Persönlich hätte ich eher "_handle" oder "_ptr" geschrieben. Ist aber nicht wichtig denke ich.

_handle ist definitiv zu lang. _ptr wäre OK.

`view_h

viewh

view_handle

view_ptr`

_h gefällt mir immer noch am besten. Wenn es genug User geben würde, könnte man bis Release 1.0 darüber abstimmen lassen (aber nicht hier im Forum, wenn dann nur auf der offiziellen Projektseite).

hustbaer schrieb:

Was mich mehr verwirrt ist die ganze MVC Sache. Ich denke einzelne Buttons/... sind "zu klein", um damit vernünftig MVC zu machen. Ich denke dass es Dinge eher verkompliziert als vereinfacht. Andrerseits hab' ich auch noch nie mit so einem System gearbeitet, kann also auch nicht sicher sein ob es nicht in der Praxis total praktisch ist.

Na, nur weil es ein Button ist? An so was würde ich nicht über solche wichtigen Dinge entscheiden. Wenn du wirklich eine Anwendung im MVC-Stil aufziehst, wirst du froh darüber sein. Ein Beispiel:

Du hast einen 3D-Game-Level-Editor. Der User kann entscheiden, ob Lichtquellen ein oder aus sein sollen, in dem Level. Wenn du in MVC-Manier denkst, wirst du nicht an Buttons (konkret Checkboxen) denken. Du wirst an Daten (Models) denken:

struct level
{
   bool sonne;
};

Das nur als Denkanstoß. Du wirst doch sicher nicht das daraus machen:

struct level
{
   checkbox sonne;
};

Weil du auf die GUI-Objekte festgenagelt bist, in dem Fall auf ein einziges Objekt und noch dazu auf einen speziellen Typ. Deshalb wirst du das erste Beispiel so umsetzen:

struct level
{
   oran::binary sonne;
};

Es ist somit völlig egal wie die Lichtquellen in dem Level verfügbar gemacht werden. Du kannst jetzt die GUI frei gestalten. Du kannst nämlich die Lichtquellen über Checkboxen ein- und ausblenden lassen. Du kannst aber auch (zusätzlich) eine Checkbox in ein Pulldown-Menü einbauen. D.h. der User hat mittlerweile zwei Möglichkeiten. Du kannst aber auch einen Adapter bauen, und eine Dropdown-List an das Model anklemmen, in der "An" und "Aus" drin steht. Du könntest aber auch anstatt eines Checkbox einfach einen Toggle-Button anklemmen. Deine Datentypen bleiben aber immer gleich. Du kannst beliebig die GUI gestalten (lassen).

Selbst der OpenGL-3D-Objekt-Renderer könnte dafür einfach das Binary-Objekt abfragen. Warum sollte er die Checkbox nach dem Status abfragen? Da fällt mir gerade auf, das ich noch einen Operator implementieren muß, damit man einfach if(level.sonne) abfragen könnte.

Auch in "ernsthaften" Anwendungen, die Formulare haben, lohnen sich Models.

Es kostet ja nichts, Models zu nutzen. Wer absolut keine Models nutzen will, kann ja die Default-Models nutzen. Denn die bietet komfortabler weise jedes View-Objekt an. Vor allem in sehr kleinen Tools macht das sicherlich Sinn.

Ich arbeite beruflich sehr viel mit Models. Habe auch schon oft Java-Code von Kollegen umgebaut, die keine Models nutzen, weil wir in einer Sackgasse gelandet sind. Deshalb sind solche Dinge wirklich nie "zu viel". Wenn du vielleicht irgendwann mal ein Projekt damit umsetzt, wirst du bestimmt den Vorteil erkennen können.

phlox81

Also das _h stört mich da auch. Fände da es besser, wenn sowas in einem Namespace handle liegen würde.
Du schreibst ja auch nich vor jede klasse algier::

Ansonsten, sieht gut aus. Du machst wohl das, wofür ich keine Zeit habe

Artchi

phlox81 schrieb:

Also das _h stört mich da auch. Fände da es besser, wenn sowas in einem Namespace handle liegen würde.
Du schreibst ja auch nich vor jede klasse algier::

Über den letzten Satz mußte ich erstmal ne Nacht drüber schlafen. Verstehe jetzt was du damit meinst.
Das aber _h so weit auf Ablehnung stösst, hätte ich jetzt nicht gedacht. Vielleicht solltet ihr es einfach nur mal eine Zeit auf euch wirken lassen?
Wie oben bereits gesagt, bis Version 1.0 kann man sowas noch ändern, da es ja nur ein Rename ist. Also noch ein Kandidat:

`

view_h

viewh

view_handle

view_ptr

handle::view`

phlox81 schrieb:

Ansonsten, sieht gut aus. Du machst wohl das, wofür ich keine Zeit habe

Danke!

Dummie

Ich muss zugeben, mich hatte das _h anfangs auch gestört, aber inzwischen bin ich der Meinung, dass es okay ist

Aber auch mit handle::view könnte ich leben. Die anderen Varianten gefallen mir aber absolut gar nicht mehr

Walli

handle::view ist doch designmäßig Quatsch. Das wäre ja fast wie alle Klassen in einen Namespace class zu packen. Ich hatte keine Zeit zu schauen, aber ist denn für den Benutzer überhaupt wichtig, dass es ein handle ist? Wenn nein, dann würde ich einfach view nehmen. Im Zweifelsfalle finde ich aber auch _h angenehmer als _handle oder _ptr.

Ad aCTa

Was meint ihr mit WPF-artig? Genauso langsam? *g*
Nein im Ernst, die GUI von VS 2010 ist bei mir sehr viel langsamer als die unmanaged GUI von VS 2008. Kein Ziel, das ich anstreben würde. Interessant wäre allerdings, einen XML-artigen Parser für eine Markup-Language zu bauen, im DOM-Style (Document Object Model von JavaScript), was am Ende ein waschechtes Binary erzeugt.

Artchi

Dummie schrieb:

Ich muss zugeben, mich hatte das _h anfangs auch gestört, aber inzwischen bin ich der Meinung, dass es okay ist

Sag ich ja, einfach mal auf sich wirken lassen.

Artchi

Walli schrieb:

handle::view ist doch designmäßig Quatsch. Das wäre ja fast wie alle Klassen in einen Namespace class zu packen. Ich hatte keine Zeit zu schauen, aber ist denn für den Benutzer überhaupt wichtig, dass es ein handle ist? Wenn nein, dann würde ich einfach view nehmen. Im Zweifelsfalle finde ich aber auch _h angenehmer als _handle oder _ptr.

Also bei view_h handelt es sich um ein Typedef auf tr1::shared_ptr<view> , d.h. ich stelle für Basisklassen passende shared_ptr-Typedefs bereit um die Tipparbeit zu verkürzen und es leserlicher zu machen. D.h. aber auch, das man kein view , button etc. als Handlenamen definieren kann, weil es ja Namenskonflikte mit den Basisklassen geben würde.

Wissen muß man also nicht, das es ein Handle ist. Das _h ist also eher aus der Not heraus gewachsen. Klar, niemand muß diese Typedefs nutzen, man kann auch immer wieder das lange std::tr1::shared_ptr<view> schreiben, wenn man drauf steht.

Ich verstehe, das das _h etwas komisch aussieht. Ich habe ja auch viele Postfix-Varianten ausprobiert! Es erschien mir dann als bester Kompromiss.

Die Frage ist, was stört denn ästhetisch wirklich? Das es nur ein "h" ist, oder stört der ""? Wenn es z.B. nur der "" ist, könnte man die Handles auch einfach in viewh , buttonh etc. umbenennen. Dann würde tatsächlich optisch der Unterschied zu den Klassennamen nicht ins Auge springen.

phlox81

Wäre es dann nicht geschickter wenn der View einen typedef handle hätte?

view::handle x;

Artchi

Ad aCTa schrieb:

Was meint ihr mit WPF-artig? Genauso langsam? *g*
Nein im Ernst, die GUI von VS 2010 ist bei mir sehr viel langsamer als die unmanaged GUI von VS 2008. Kein Ziel, das ich anstreben würde.

Ich habe noch nie eine WPF-Anwendung benutzt. Kann dazu nichts sagen. Kenne nur Demos, die WPF zeigen. th69 ging es sicherlich nicht darum WPF zu wrappen. Ich glaube, er will einfach nur etwas flexibleres, als die nativen Widgets.

Ich muß hier mal deutlich machen, das Algierlib erstmal das Ziel hat, eine gute Basis-Lib zu sein. So zusagen was die STL oder Boost in ihren Bereichen sind. Das kann man durch Qualität (nicht nur Implementierung, sondern auch Doku, Einfachheit usw.) erreichen. Und die Lizenz ist denke ich auch für jeden akzeptabel.

Schon alleine wegen der Manpower, ist jedoch Feature-mäßig zur Zeit nicht mehr möglich! Aber ich kann mir vorstellen, das jemand sagt "Ich nehme Algierlib, und bau darauf auf, um was WPF-artiges zu realisieren." Oder auch um einfach fehlende Features zu entwickeln, die Algierlib wegen seinem Basischaracter nicht bietet. Deshalb darf die Library auch nicht zu sehr explodieren und sollte einen gemeinsammen Nennen setzen, aber erweiterbar sein.

Ad aCTa schrieb:

Interessant wäre allerdings, einen XML-artigen Parser für eine Markup-Language zu bauen, im DOM-Style (Document Object Model von JavaScript), was am Ende ein waschechtes Binary erzeugt.

Ja, das könnte natürlich außerhalb des Algierlib-Projektes entwickelt werden, und dabei Algierlib nutzt. Ich weiß ja nicht was in ein paar Jahren sein wird, man könnte deine Idee z.B. in den Algierlib-Download als Gimmik mit anbieten (Lizenz muß kompatibel sein). Oder vielleicht als optinale Erweiterungen in das Projekt einfließen lassen. D.h. eine Lib-Sammlung macht, wie es bei Boost ist. Aber speziell für GUI.

Das sind alles Wünsche, die ich alleine überhaupt nicht erfüllen kann! Ich kann froh sein, wenn ich in absehbarer Zeit Version 1.0 für MS-Windows und X11 in guter Qualität fertig bekomme!

Blue-Tiger

*g* Huch, der "_h"-Kommentar hat ja ganz schoen was losgetreten

Artchi schrieb:

Die Frage ist, was stört denn ästhetisch wirklich? Das es nur ein "h" ist, oder stört der ""? Wenn es z.B. nur der "" ist, könnte man die Handles auch einfach in viewh , buttonh etc. umbenennen. Dann würde tatsächlich optisch der Unterschied zu den Klassennamen nicht ins Auge springen.

Mich persoenlich stoert das gesamte "_h", weil ich vermutlich in 99.999% der Faelle kein Interesse daran habe, dass ich grad mit 'nem Handle hantiere. Und soweit ich das gesehen hab, verwendet die Lib die meiste Zeit sowieso das Handle und nicht den eigentlichen Typ. Sprich, ich wuerde das view in sowas wie view_t umbenennen und den view_h zum view machen. Letztendlich verwendet der Benutzer naemlich sowieso dieses Handle. Aber ich vermute wenn ich wirklich mal mit der Lib arbeiten wuerde (dafuer brauch ich aber den Linux-Port ), koennt ich mich auch ans _h gewoehnen. Namespaces faend ich aber auch keine schlechte Loesung (und machen fuer mich durchaus Sinn, da muss ich Walli widersprechen). Nur seh ich's schon kommen, dass ich dann irgendwann im Code

using namespace algier; using namespace algier::handles

stehen haette und der Compiler sich wieder nicht auskennt, was ich denn nun mein, wenn ich button schreib.

Artchi schrieb:

Blue-Tiger schrieb:

Aber wrap bitte GTK oder Qt, nicht Xlib direkt!

Xlib sicherlich nicht. Ich habe da noch keine endgültige Entscheidung getroffen. Ich habe aber erstmal OpenMotif für einen Prototyp-Port vorgesehen. So kann ich sowohl die Gnome- als auch KDE-Fraktion nicht verärgern. OpenMotif ist eine stabile API. Das Look&Feel ist auch nicht mehr ganz so altbacken, da seit dem letzten Release UTF-8, PNG und Anti Aliasing Fonts unterstützt wird.

Verschreckst du damit nicht eher sowohl Gnome als auch KDE-User? Wenn ich mein gtk-Theme aender, ziehen Qt-Apps mittlerweile automatisch nach, weil gerade bei den zwei grossen (gtk/Qt) halbwegs Interopabilitaet besteht. Im Idealfall merk ich nichtmal mehr, welche Lib der App zugrund liegt. K. A. ob das auch fuer OpenMotif gegeben ist. Bei wxWidgets stoerts auch niemand, dass sie gtk wrappen statt Qt.

Artchi schrieb:

Du hast einen 3D-Game-Level-Editor. Der User kann entscheiden, ob Lichtquellen ein oder aus sein sollen, in dem Level. Wenn du in MVC-Manier denkst, wirst du nicht an Buttons (konkret Checkboxen) denken. Du wirst an Daten (Models) denken:

[ ... Beispielcode... ]

Es ist somit völlig egal wie die Lichtquellen in dem Level verfügbar gemacht werden. Du kannst jetzt die GUI frei gestalten. Du kannst nämlich die Lichtquellen über Checkboxen ein- und ausblenden lassen. Du kannst aber auch (zusätzlich) eine Checkbox in ein Pulldown-Menü einbauen. D.h. der User hat mittlerweile zwei Möglichkeiten. Du kannst aber auch einen Adapter bauen, und eine Dropdown-List an das Model anklemmen, in der "An" und "Aus" drin steht. Du könntest aber auch anstatt eines Checkbox einfach einen Toggle-Button anklemmen. Deine Datentypen bleiben aber immer gleich. Du kannst beliebig die GUI gestalten (lassen).

Das Beispiel find ich gut, macht klar warum das so ist. Macht echt Sinn! Aber: mir widerstrebt es, meine Applikationslogik von einer Fremden Lib (Oran) abhaengig zu machen. Grad bei so Sachen wie Datenstrukturen: was, wenn ich das ganze spaeter mal mit Swig interfacen will, oder ausserdem noch Library X einstetzen will um statistische Auswertungen zu machen oder..... da hab ich dann mit einem schlichten int oder bool sicher weniger Probleme/Umstaende als mit einem oran::binary . Ich wuerds schoen finden, wenn Oran Wrapper fuer die Grunddatentypen anbieten wuerde (die dann eine Referenz speichern o. AE.), damit ich meine eigentliche Applikationslogik frei von oran halten koennte.

(Disclaimer: ich theoretisiere nur! Habe Algier nie verwendet, vllt. sind das alles auch keine Probleme, die sich in der Praxis stellen)

Artchi

phlox81 schrieb:

Wäre es dann nicht geschickter wenn der View einen typedef handle hätte?
view::handle x;

Bin ich bisher blind gewesen! Da ich sowas schon in der Lib gemacht habe. Zwar nicht mit Typedefs für Smartpointer, aber Typedefs für tr1::function habe ich als public in die Klassen geschrieben. Das ist definitiv besser als ein Namespace!

Also ich sag mal, das sind bisher die Kandidaten, die ich pers. bevorzugen würde:

`view_h

viewh

view::handle`