Das beste C++-GUI-Framework gesucht

Unter der Prämisse, dass der GUI-Teil des .NET-Frameworks als das Non Plus Ultra angesehen wird: Welches Framework für handelsübliches C++ (also nicht C++ mit .NET) würdet ihr das beste nennen? Bitte nur Frameworks aufzählen, die tatsächlich mit normalem* C++ auskommen und nicht auf speziell für dieses Framework zugeschnittene Compilererweiterungen angewiesen sind (wie bei der VCL).

*Mit normal meine ich bloß, dass keine compilertechnischen Spracherweiterungen nötig sind. Selbstverständlich darf das Framework auf den betriebssystemspezifischen Funktionen und Bibliotheken (WinAPI etc.) basieren, denn mit reinem ISO-C++ kann man ja sowieso nichts Grafisches machen.

Warum kommt hier eigentlich dauernd jemand auf die Idee zu fragen, was das "beste" C++-Framework wäre?

Ich hab nicht nach dem besten gefragt, sondern nach dem besten, wenn man das .NET-Framework als das beste ansieht. D.h. ich hab eigentlich nach dem gefragt, das dem .NET-Framework am nächsten kommt.

zwutz

was willst du?
Einen Ersatz fuer .NET? nimm Mono

ansonsten sieh dir die diversen "welche GUI-Bibliothek ist die Beste"-Threads hier im Forum an, da dort bereits zu genuege Empfehlungen unter Nennung der Vor- und Nachteile gemacht wurden.

Ich suche ein Framework, das dem .NET-Framework von der Bedienung und den Eigenschaften her am nächsten kommt (auf GUI-Programmierung bezogen; die ganzen anderen tausend Funktionen für Datenbanken und so'n Zeug mein ich jetzt nicht). Aber ich suche natürlich ein Framework für normales, "handelsübliches" C++, nicht für C++/CLI (das heißt, Mono käme wohl nicht in Frage, da ja Mono nur eine weitere .NET-Implementierung ist und keine Win32-Anwendungen, sondern eben .NET-Anwendungen erzeugt).

Würde sagen, da kommt gtkmm dem ganzen sehr Nahe. Wenn du einen Prä-Präprozessor akzeptierst (ich habe selbst da immer etwas Bauchschmerzen), ist Qt auch ein sehr guter Kandidat.

Bulli schrieb:

Würde sagen, da kommt gtkmm dem ganzen sehr Nahe. Wenn du einen Prä-Präprozessor akzeptierst (ich habe selbst da immer etwas Bauchschmerzen), ist Qt auch ein sehr guter Kandidat.

qt hat aber auch nur sehr wenige Makros!! Und in der praxis brauchst du hauptsächlich Q_OBJECT

minimal! schrieb:

Bulli schrieb:

Würde sagen, da kommt gtkmm dem ganzen sehr Nahe. Wenn du einen Prä-Präprozessor akzeptierst (ich habe selbst da immer etwas Bauchschmerzen), ist Qt auch ein sehr guter Kandidat.

qt hat aber auch nur sehr wenige Makros!! Und in der praxis brauchst du hauptsächlich Q_OBJECT

Genau dieses Q_OBJECT wird für den Prä-Präprozessor benötigt! Wer da keine Bauchschmerzen bekommt, wird sich auch über normale Makros nicht beschweren.

wxWidgets.
Einmal schreiben, überall kompilieren, geht sogar auf Handhelds bzw PocketPCs etc. Ich finds einfach gut (: und es ist kostenlos auch für kommerzielle Anwendungen und frei noch dazu.
mfg

nurf

Kommt im Endeffekt auf den Entscheider an ...
Aber heutzutage läuft es bei vernünftigen Menschen auf wxWidgets oder QT hinaus.

Aber es gibt ein paar wichtige Punkte zu bedenken.

Lizenz : wxWidgets schlägt QT eindeutig

Platform: wxWidgets unterstützt X11, Motif und GTK1,2 (für Linux)
Wer einfach nur auf Linux portieren will, dem sei dieser Punkt egal, aber wie schon erwähnt, läuft wxWidgets sogar auf Palms und manchen Handys und fast jedem Compiler ( STL ist nicht notwendig ).

Abwärtskompatibilität ist wxWidgets ein Tick besser, solange man bei QT im Major-Release bleibt, gibts da aber auch keine Probleme ( QT3 != QT4 ).

Sonstige Unterschiede :

Qt bietet das Webkit.

In wxWidgets gibts zur Laufzeit ladbare GUIs, definiert in XML-Files. So kan man z.B. die Sprache der Applikation editieren ohne neu kompilieren zu müssen.
(Falls es sowas in QT gibt, korrigiert mich bitte.)

Es gibt viele Spinoffs von wxWidgets, die eng mit dem Projekt verbunden sind ...
wxPython, wxJavaScript

Warum empfehlt ihr wxWidgets? Der Fragesteller wollte was das den WindowsForms nahe kommt. Und das tut wxWidgets nicht. Ihr geht auf die Frage des Threads überhaupt nicht ein, sondern empfehlt nur eure pers. Favoriten, unabhängig von der Frage.

zwutz

nurf schrieb:

In wxWidgets gibts zur Laufzeit ladbare GUIs, definiert in XML-Files. So kan man z.B. die Sprache der Applikation editieren ohne neu kompilieren zu muessen.
(Falls es sowas in QT gibt, korrigiert mich bitte.)

Sprache aendern: http://doc.trolltech.com/4.4/i18n.html
UI-Files zur Laufzeit laden: http://doc.trolltech.com/4.4/quiloader.html

also nichts neues

GUI Richie schrieb:

Ich hab nicht nach dem besten gefragt, sondern nach dem besten, wenn man das .NET-Framework als das beste ansieht. D.h. ich hab eigentlich nach dem gefragt, das dem .NET-Framework am nächsten kommt.

Am nächsten kommt dem wohl die VCL, weil sie halt vom gleichen Menschen Designt wurde, wie die WinForms.

Das einzige, was mir einfällt, was ja auch schon genannt wurde ist gtkmm.

Aber mal im Ernst: Wenn du WinForms so wahnsinnig toll findest, dann programmier halt damit. Das kannst du ja auch mit .NET+C++ machen. Ansonsten würde ich mein GUI-Toolkit nach anderen Kriterien aussuchen.

Und dann wären wir bei der Frage, die hier schon Millionen mal gestellt wurde...

Mensch Kinder... GUI sollte eigendlich nur Beiwerk sein. Im Prinzip ist es recht unwichtig welche Lib man nutzt. In gut desingten Programmen ist das auch realisiert.... Darum geht ja auch in Windows kaum was ohne einen Knopf Also macht eure Sachen modular und ihr könnt an ein und dem selben Projekt 20 GUIs ausprobieren ...

Bulli schrieb:

minimal! schrieb:

Bulli schrieb:

Würde sagen, da kommt gtkmm dem ganzen sehr Nahe. Wenn du einen Prä-Präprozessor akzeptierst (ich habe selbst da immer etwas Bauchschmerzen), ist Qt auch ein sehr guter Kandidat.

qt hat aber auch nur sehr wenige Makros!! Und in der praxis brauchst du hauptsächlich Q_OBJECT

Genau dieses Q_OBJECT wird für den Prä-Präprozessor benötigt! Wer da keine Bauchschmerzen bekommt, wird sich auch über normale Makros nicht beschweren.

Naja ... warum bekommt man deshalb Bauchschmerzen? Ich glaub nicht dass jemand, der mit Qt programmiert den Drank verspürt eigene Instanzen Q_OBJECT zu nennen oder was soll passieren?

giovannii schrieb:

Naja ... warum bekommt man deshalb Bauchschmerzen? Ich glaub nicht dass jemand, der mit Qt programmiert den Drank verspürt eigene Instanzen Q_OBJECT zu nennen oder was soll passieren?

Stell die einfach mal vor, was passieren würde, wenn jede Bibliothek einen eigenen Präprozessor mitbringen würde.

Immer die selbe Disskussion, wo jeder meint es besser zu wissen.

Wenn du WinForms willst, nimm WinForm. ABER, erwarte nicht, das es eine Library gibt die das gut und genauso toll nachbaut. Wenn du dich nach einer GUI Bibliothek umsiehst, solltest du andere Kriterien verwenden.