Wie sieht für euch die perfekte GUI-Library aus?

borg

cd9000 schrieb:

borg schrieb:

- nichts neuimplementieren was es in der stl schon gibt! ( std::string statt QString etc.)

Das ist AFAIK nicht so einfach, wie es sich anhört. Das Problem ist, dass std::string nur für Strings mit konstanter Zeichenbreite ausgelegt ist, also ASCII, ANSI, UCS-irgendwas.

Bei GUI-Systemen wird aber (auch afaik) selten UCS-4 (konstant 32 Bit breite Zeichen) verwendet, sondern aus Platzgründen viel häufiger ein Multibyte-Zeichensatz wie UTF-8 oder UTF-16. Sowas lässt sich mit std::string aber nicht gut verarbeiten.

ja, ok bei strings könnte man ja zweispurig fahren und einfach beides anbieten. (zumindest sollte man einfach einen std::string in einen QString schieben können, das würde mir schon genügen.) strings sind da aber die ausnahme, die ganze qtl ist imo überflüssig.

das problem ist, es gab Qt schon vor der stl.

Träumer schrieb:

Allerdings suche ich nicht so ich sag mal "oberflächliche Features", wie
Plattformunabhängigkeit, RAID, etc .. Eben typische Punkte, mit denen die
Hersteller für sich werben.

gtkmm features (umsortiert) schrieb:

- No macros.
- Full use of C++ namespaces.
- Polymorphism.
- Type-safe signal handlers, in standard C++.

suchender schrieb:

b) Keine Makros
c) Verwendung von Namespaces statt Prefixes
...
d) Vernünftige Veerbungshierarchie und Polymorphismus, ...
d) Ereignisse sollten durch Zeiger auf Funktionen bzw. Methoden realisiert
werden

Falls du dir bitte nochmal alle 3 Quotes durchliest, fällt dir vielleicht
etwas auf (und damit mein ich nicht, dass im Alphabet nach e nicht
wieder d gefolgt von noch einem d kommt ..).

Um es noch deutlicher darzustellen, ich suche wie bereits gesagt keine Features,
die man auf der Homepage nachlesen kann, denn die sind meist nur oberfächlich.
Ich würde gerne wissen, was euch gefällt, wenn man sich tiefer mit einer
Bibliothek beschäftigt.

Ein weiteres Beispiel wär ja zum Beispiel die strikte Trennung zwischen UI und
Logik, also sozusagen ein "built-in MVC-Pattern". Wie machen das eure favourite
GUI Libs? Aber eben nicht nur das, vielleicht fallen euch ja noch solche Punkte
ein.

Hoffe damit ist klarer rausgekommen, was ich wollte.

Artchi

Also ich selbst bastel zur Zeit an einer GUI-Library. Mir ist schon bewusst, das ich als Einmann-Projekt keines Falls an die Konkurrenz ran komme. Aber ich habe dieses Projekt angegangen, weil mich an den bisherigen Libs auch vieles stört. Ihr könnt euch vielleicht noch an meinen FOX-Toolkit-Thread erinnern?

Ich habe erst versucht die original Win32-GUI zu kapseln. Muß aber sagen, das es ein Horror war! Man bricht sich wirklich einen Ast ab, um das Win32-Konzept irgendwie objekt orientiert unter zubringen. Letztendlich hat es mich nicht gewundert, das Toolkits wie die MFC oder wxWidgets mit Makros um sich werfen, um das Win32-nativ-Problem zu lösen. Deshalb bin ich übergegangen meine Widgets selbst zu zeichnen. So kann man sich mehr auf das OOD der Library konzentrieren, anstatt sich damit rumzuschlagen, wie man das Win32-Konzept objekt orientiert kapselt. Macht auch irgendwie keinen Sinn die Win32-GUI zu kapseln. Man wird in der "Mächtigkeit" total eingeschränkt.

Jetzt zeichne ich zwar meine Widgets selbst, bin jetzt aber dabei ein gutes OOD mit C++-Möglichkeiten zu gestalten. Muß aber feststellen, das ich ziemlich Java-geschädigt bin.

Ich habe mal schnell eine FAQ zu meiner GUI Lib zusammen geschustert, falls es jemanden interessiert:

http://sgl.kharchi.de

Wie weit ich letztendlich damit komme, weiß ich nicht. Mal schauen...

Artchi

Träumer schrieb:

Um es noch deutlicher darzustellen, ich suche wie bereits gesagt keine Features,
die man auf der Homepage nachlesen kann, denn die sind meist nur oberfächlich.
Ich würde gerne wissen, was euch gefällt, wenn man sich tiefer mit einer
Bibliothek beschäftigt.

Ein weiteres Beispiel wär ja zum Beispiel die strikte Trennung zwischen UI und
Logik, also sozusagen ein "built-in MVC-Pattern". Wie machen das eure favourite
GUI Libs? Aber eben nicht nur das, vielleicht fallen euch ja noch solche Punkte
ein.

Ich arbeite täglich beruflich mit der Java SWING Library. Und sie gefällt mir wirklich sehr gut, vom Konzept her. Jetzt mal völlig losgelöst ob sie schnell oder langsam ist, das ist ja nicht das Thema!!! Jedenfalls kann ich als Programmierer mit Swing so ziemlich alle Wünsche meines Kunden lösen, was GUIs angeht. Meistens hab ich nach wenigen Minuten ein Konzept das ganz einfach funktioniert. Eine Outlook-Sidebar war gewünscht. Hem... klar, hat mein Kollege erst mit google was fertiges gesucht. Gabs auch was, hat aber Kohle gekostet... hat er dann innerhalb eines Nachmittags selbst implementiert, obwohl er Swing-Unerfahren war (er hat vorher Web-Anwendungen gemacht). Jedenfalls kann man ruck zuck in Swing einsteigen, das Konzept verstehen und kann locker seine eigenen Komponenten zusammen schustern.

Sowas wie Swing vermisse ich in C++. Habe schon mal Qt ausprobiert, und fand Qt ansich schon sehr intuitiv, bis auf dieses komische qmake. Fand auch nicht so toll, das es ein QString gab usw.

Daniel E.

cd9000 schrieb:

Das Problem ist, dass std::string nur für Strings mit konstanter Zeichenbreite ausgelegt ist, also ASCII, ANSI, UCS-irgendwas.

Bei GUI-Systemen wird aber (auch afaik) selten UCS-4 (konstant 32 Bit breite Zeichen) verwendet, sondern aus Platzgründen viel häufiger ein Multibyte-Zeichensatz wie UTF-8 oder UTF-16. Sowas lässt sich mit std::string aber nicht gut verarbeiten.

Operiert QString intern wirklich direkt auf UTF-8-Strings? Das halte ich UTF-8 eher für ungeschickt. Ich würde intern 32bit-Typen anbieten und Umwandlungsoperationen für die Ein- und Ausgaben bereitstellen; string, wstring und Freunde machen genau das, man muß sich evtl. eine Facette basteln.

So ungeschickt ist das IMHO gar nicht. Wenn man mal ehrlich ist, braucht man bei Strings wirklich nur äußerst selten random access. In diesem Fall ist es natürlich ratsam, seinen String in nen UCS-4 String zu konvertieren. Aber ich behaupte einfach mal und das gerade im Zusammenhang mit ner GUI-Lib, dass random access fast nie benötigt wird und UTF-8 ist für westliche Texte einfach extrem platzsparend.
Im Grunde ist ja das einzige, was echt stört, die std::string-Klasse, die auf sowas nicht ausgelegt ist. Aber da die Klasse eigentlich eh generell nicht so das Zeug dazu hat, zum Standard-String zu werden (man beachte auch, dass libs fast wirklich immer char*s fressen), da erstens schlecht designt und zweitens in der Praxis nicht so leicht mit DLLs zu verwenden, hab ich auch nichts dagegen, wenn eine lib ihre eigene String-Klasse verwendet. Hat man übrigens auch beim Firefox gemacht, außerdem haben die noch verschiedene String-Klassen implementiert, die alle bei was anderem besonders geil sind.
Hier muss man echt mal die Ausgangssituationen vergleichen... man kann zu Java stehen wie man will, aber es gibt einfach keine Java-Lib die nicht java.lang.String verwendet und das ist gut so.

Hallo,

du bist kein aufmerksamer Leser @Träumer:

Ich habe hierauf geantwortet:

Träumer schrieb:

Wie sieht für euch die perfekte GUI-Library aus?

Und folgende Aussagen von mir scheinst du nicht gelesen zu haben:

suchender schrieb:

GTKmm kommt meinen Vorstellungen nahe, aber unter Windows kapselt es auch GTK+ und dieses wiederum kapselt nicht die WinAPI-Steuerelemente, sondern zeichnet diese mit GDK selbst. Sieht daher auf Windows nicht nativ aus. Man muss einer Anwendung die man mit GTKmm für Windows entwickelt daher auch die GTK+ und GTKmm DLL's mitgeben, da die meisten Windows-User diese vorher nicht haben. Ausserdem scheint es unter Windows laut Aussagen der GTK-Entwickler noch nicht ausgereift zu sein und es zu unerklärlcihen Abstürzen kommt. Diese Info habe ich vor einem halben Jahr gelesen. Ich weiss nicht, wie die Situation momentan ist.

Ausserdem steht GTKmm in Konflikt mit folgenden Anforderungen:

suchender schrieb:

3. Sollte nach Möglichkeit jeweils die GUI-API der zugrundeliegenden
Plattform kapseln. Z.B. WinAPI für Windows, für UNIXe XLib oder GTK+.
Dadurch sehen die Anwendungen jeweils nativ aus

4. Sollte möglichst schlank sein. Ein "Hello world"-Programm mit
einem leeren Fenster sollte bei statischer Bindung nicht größer
als 2 MB sein.

Falls mein Beitrag dir zu oberflächlich war, hättest du ihn auch einfach ignorieren können, statt ihn zur Hälfte zu lesen und dann auch noch arrogant zu kommentieren.

Ich weiss nicht was du für Killerfeatures von einer GUI-Bibliothek erwartest, aber mir würde schon eine genügen, die alle von mir genannten Merkmale hat. Kannst du mir eine nennen?

Träumer schrieb:

Geht eben darum, dass in Avalon ein Control alles beinhalten kann, nicht nur
Text und andere Controls.

Das habe ich bisher nicht vermisst.

Gruß

Blue-Tiger

Träumer schrieb:

Um es noch deutlicher darzustellen, ich suche wie bereits gesagt keine Features,
die man auf der Homepage nachlesen kann, denn die sind meist nur oberfächlich.
Ich würde gerne wissen, was euch gefällt, wenn man sich tiefer mit einer
Bibliothek beschäftigt.

Ein weiteres Beispiel wär ja zum Beispiel die strikte Trennung zwischen UI und
Logik, also sozusagen ein "built-in MVC-Pattern". Wie machen das eure favourite
GUI Libs? Aber eben nicht nur das, vielleicht fallen euch ja noch solche Punkte
ein.

Hoffe damit ist klarer rausgekommen, was ich wollte.

Trennung zwischen GUI und Logik IMO was, worum sich hauptranging der Programmier kuemmern soll, nicht die GUI lib. Was _ich_ mir wuenschen wuerde, waeren hauptsaechlich Dinge, die du als Oberflaechlich abtust:

eine ordentlich durchdesignte Library, die all das ausnutzt, was C++ zu bieten hat:
die STL, inline statt Makros, Exceptions, Namespaces, etc. etc. etc. Dazu noch ein paar Gimmicks wie ordentliches RAD-Tool oder integriete Threading-Lib, gemischt mit einfacher Bedienung (kein moc inzwischen), native Widgets (die Traum-GUI-Lib ist selbstredend Multiplattform) und moeglichst keine 2 MB-"Hello, World" Binaries oder xtausend mitzuschleppende DLLs (gtkmm auf Windows, anyone)...

Dann waer ich gluecklich. Das sind echt Dinge, die ich toll faend. Alles andere ist schnickschnack :p

Hallo,

Full Ack @Blue-Tiger.

Als ich mal ein wxWidget-"Hello world" statisch gelinkt habe, hatte ich hinterher ein 17 MB Binary. Deshalb wäre ich mit einer 2 MB Obergrenze schon fast zufrieden. Wenn man dann noch einige andere Controls in das Fenster packt wird das Binary meistens nicht viel größer.

Gruß

Artchi schrieb:

Ich arbeite täglich beruflich mit der Java SWING Library. Und sie gefällt mir wirklich sehr gut, vom Konzept her. Jetzt mal völlig losgelöst ob sie schnell oder langsam ist, das ist ja nicht das Thema!!! Jedenfalls kann ich als Programmierer mit Swing so ziemlich alle Wünsche meines Kunden lösen, was GUIs angeht. Meistens hab ich nach wenigen Minuten ein Konzept das ganz einfach funktioniert. Eine Outlook-Sidebar war gewünscht. Hem... klar, hat mein Kollege erst mit google was fertiges gesucht. Gabs auch was, hat aber Kohle gekostet... hat er dann innerhalb eines Nachmittags selbst implementiert, obwohl er Swing-Unerfahren war (er hat vorher Web-Anwendungen gemacht). Jedenfalls kann man ruck zuck in Swing einsteigen, das Konzept verstehen und kann locker seine eigenen Komponenten zusammen schustern.

Kannst du vielleicht ein wenig näher beschreiben, warum es so einfach ist?
Klingt jetzt vielleicht ein wenig doof und ist auch eventuell nicht beantwortbar
aber es muss ja einen Grund geben, warum es so einfach ist. Wird wohl kaum
zufälligerweise sein

suchender schrieb:

Falls mein Beitrag dir zu oberflächlich war, hättest du ihn auch einfach ignorieren können, statt ihn zur Hälfte zu lesen und dann auch noch arrogant zu kommentieren.

Blue-Tiger schrieb:

Was _ich_ mir wuenschen wuerde, waeren hauptsaechlich Dinge, die du als Oberflaechlich abtust:

Es geht mir halt darum, dass solche Punkte eben, in einer neuen GUI Library
sowieso vorhanden sein müssen. Die bisherigen Librarys sind ja an ihre alten
Konventionen, bzw ihre alte Schnittstelle gebunden, daher ist es auch kein Wunder,
dass sie nicht alle eure Punkte erfüllen können.

grüße

Träumer schrieb:

Kannst du vielleicht ein wenig näher beschreiben, warum es so einfach ist?
Klingt jetzt vielleicht ein wenig doof und ist auch eventuell nicht beantwortbar
aber es muss ja einen Grund geben, warum es so einfach ist. Wird wohl kaum
zufälligerweise sein

Wenn du es nicht glaubst, warum probierst du es dann nicht aus? Natürlich ist es auch nicht Zufall. Du hast praktisch kein Resourcen-Management und Swing ist einfach extrem flexibel. Jedes JComponent ist ein Container, du kannst überall weitere Components reintun, du kannst deine eigenen Components schreiben ...
Bei GUI-libs, die auf native Widgets zurückgreifen, bist du darauf beschränkt, was die Schnittmenge aller Systeme kann. Bei Swing hast du solche Einschränkungen nicht. Swing schränkt dich halt einfach nicht ein, so dass du irgendwie um ein Problem herumbauen müsstest.

Die perfekte GUI Lib muss nur eine Bedingung erfüllen:
Sie ist NICHT in C++ geschrieben

Korbinian

javax.swing.* und darin verwendete reste aus awt. erfüllt alles wichtige

einheitliche schnittstellen
sinnvolle interfaces
easy-to-use (im sinne von intuition und benutzbarkeit der komponenten. als beispiel: ich speichere meine objekte in eine JListView, angezeigt werden sie über die toString methode, und wenn ich ein getSelected mache, bekomme ich einen zeiger auf das objekt als solches. wahnsinn. so kann ich perfekt arbeiten!)
automatisches layout. hat man sich einmal dran gewöhnt gibt mans nicht mehr her
rad entwicklungstools vorhanden (eclipse visual editor)

ihr merkt, ich bin ein java fan geworden...

SideWinder

@Korbinian: Full ACK. Ich habe in der Schule mit Java zuerst beginnen müssen und jetzt bin ich vollkommen umgestiegen. Es ist alles so schön logisch, gut designed und einfach. Bevor ich mir in C++ überlegt habe welche GUI ich überhaupt benutzen möchte steht die GUI mit Java bereits. Ganz einfach kann man per MVC-Modell eigene Komponenten hinzufügen und das System der Listener ist auch toll (keine dummen Zeiger auf Funktionen (oder gar Methoden) mehr).

MfG SideWinder

Ich stimme zu. Allerdings muss ich schon auch zugeben, dass mich die delegates von .Net noch mehr reizen als die Listener. Viele Listener-Klassen zu haben, ist schon hässlich, viele Event-Methoden nicht. Aber die Winforms kommen vom Design her nicht an Swing ran.
Allerdings mussten die auch das ugly WinAPI kapseln.

EDIT: Man beachte vor allem auch anonyme delegates. So macht das richtig Freude, weil man sich nicht mal mehr so direkt für die Signatur einer Methode interessieren muss. static? private? protected? Wie waren nochmal die Parameter für dieses Event-delegate?

myButton.Click  +=  { Console.Out.WriteLine("Jo oida, ich wurde angeklickt."); }

Steven

Ich finde gtkmm ist eigentlich schon ziemlich gut, folgende Dinge nerven aber:

Das Widget für Listen und Bäume (Gtk::TreeView) hat eine unnötig komplizierte API und ist daher eigentlich nur schlecht zu gebrauchen.
Es gibt ein zu großes Durcheinander, wann man jetzt Objekte, Zeiger oder RefPtr übergeben muss.
gtkmm ist, wenn man keinen Paketmanager hat, der die Abhängigkeiten selbst auflöst, relativ schwierig zu installieren. Besonders lustig wird es, wenn man nicht nur ein gtkmm-Programm unter Windows ausführen will, sondern auch noch unter Win32 gtkmm-Programme entwickeln will.

Ansonsten lobe ich mir aber das saubere Signalkonzept (ohne Metacompiler wie bei QT und keine Makros wie z.B. bei wxWidgets oder Fox), die Aufteilung in Namespaces und die Unterstützung von STL-Containern.

Helium

SideWinder schrieb:

das System der Listener ist auch toll (keine dummen Zeiger auf Funktionen (oder gar Methoden) mehr).

Ne, tut mir leid, das kann ich überhaupt nicht haben. Das Prinzip ist einfach doof.

Helium schrieb:

SideWinder schrieb:

das System der Listener ist auch toll (keine dummen Zeiger auf Funktionen (oder gar Methoden) mehr).

Ne, tut mir leid, das kann ich überhaupt nicht haben. Das Prinzip ist einfach doof.

Verstehe ich nicht. Kannst du das mal erklären? Aus meiner Sicht ist das eine ganz kleine Variation des Observer-Patterns, das da implementiert wurde. Da ist also nichts Schlimmes dran und wird von vielen als gute Lösung angesehen. Wenn du sagst, dass es Mist ist, sollte also schon ein bischen Rechtfertigung bzw. Erklärung dahinter stehen.

Helium

Ich find das Observer-Pattern allgemein meistens doof. Das wirkt meistens so, als müsste man irgenwie um die fehlende Möglichkeit Funktionen/Methoden zu speichern etwas herumbasteln. Dann hat man seinen Observer, die ganzen Listener, ... wobei alles deutlich einfacher ginge (siehe z.B. die von Optimizer angesprochenen Delegates).

Es gibt da so einige gängige Design-Pattern, die ich total überflüssig finde, weil man mit Delegates, bzw. vergleichbarem eine deutlich einfacher handzuhabende Lösung formulieren kann.

Helium schrieb:

Das wirkt meistens so, als müsste man irgenwie um die fehlende Möglichkeit Funktionen/Methoden zu speichern etwas herumbasteln.

Diese Ansicht kann ich auch nicht ganz teilen. Ich finde nichts hässlicher als die Funktionspointer und Methodenpointer in C++. Vor allem, dass sie nicht austauschbar sind.
Delegates sind natürlich sehr butterweich. In .Net ist es so geil, weil es egal ist, ob die Methode static ist oder nicht und sogar virtuelle Methoden funktionieren. Es muss einfach nur die Signatur passen.
Aber wenn ich wählen müsste zwischen C++ - Pointer und Observer, ist die Wahl für mich klar.