Suche einfache GUI-Bibliothek
-
Hallo,
ich lerne gerade C++ und habe nun mein erstes Buch über normale Konsolenprogramme fertig gelesen.
Von Java kenne ich die Klassenbibliothek StiftUndCo, mit der man sehr einfach(e) Oberflächen erstellen kann.
Meine Frage: Gibt es soetwas ähnliches auch für C++, um einfachere Guis ohne viel Aufwand zu erstellen? MFC oder Qt scheinen mir da etwas komplexer!? Versteht mich nicht falsch, ich will natürlich später auch "richtige" Guis machen, aber so als Zwischenlösung und zum Ausprobieren würde ich gerne etwas anderes haben
Gruß, ph4nt0m
-
Also, bei MFC kannst du zum erstellen von Oberflächen den ResourceEditor nutzen. Der ist nach dem Prinzip WYSIWYG.
Mit dem QTDesigner von QT ist es so ebenfalls einfach möglich Oberflächen zu erstellen.
-
Klar, das Designen ist vielleicht einfach (Drag&Drop), aber wie sieht es denn mit der eigentlichen Funktionalität aus? Die Buttons&Co sollen ja auch was machen
Also bei dem StiftUndCo Beispiel war das super einfach. Es gibt eine überschaubare Anzahl an Methoden, die alle selbsterklärend sind und mit denen man sehr einfach zu recht kommt.
Wie ist das bei MFC? Sind alle "Objekte" dann als Instanz einer Klasse ansprechbar und liefern mir ebenfalls eine komplette Liste der verfügbaren Methoden?
Gruß, ph4nt0m
-
Ja, wenn du zum Beispiel einen Button auswählst und dann auf STRG + W drückst bekommst du ne Übersicht welche Nachrichten und Methoden es gibt. Zumindest ist dies in der VS 6.0 Version so. Ob es in der neuen Version 2003 ebenfalls so ist kann ich nicht beurteilen.
-
Man kann generell sagen, das sich die C++ GUI Libs in zwei Gruppen teilen: die alten, die noch sehr Makro-Orientiert sind, und die, die neuer sind und ein schnöneren C++ Stil haben. Aber die haben auch wiederrum alle in der jeweiligen Gruppe Vor- und Nachteile, so das man sich wirklich den Kopf zerbrechen könnte.
Wenn es dir erstmal nur darum geht, überhaupt in C++ schnell und einfach GUIs zu entwickeln, ohne tausend andere Faktoren zu bedenken (will ich Look&Feels, will ich native Widgets, welche Lizenz, bla bla bla???), empfehle ich dir das FOX-Toolkit.
FOX-Toolkit ist meiner Meinung nach der beste Kompromiss zur Zeit, auch was die Einfachheit der Installation und des Codes angeht. Am ersten Abend wirst du sowohl die ganze Library gebuildet haben und das erste Fenster mit Button erstellt haben. Es sind auch massig Beispielsourcen bei dem FOX-Toolkit bei. Es gibt ein sehr gutes Tutorial und eine umfangreiche Referenz.
-
Was oftmals vergessen wird ist, dass man mit dem Ressourceneditor von VC nur Dialoge erstellen kann, jedoch keine Hauptfenster, die muss man immernoch von Hand machen (wobei es da natürlich auch fertige Klassen gibt in der MFC, aber ums programmieren kommt man nicht rum).
Der QT Designer kann Oberflächentechnisch alles erstellen, aber die Funktionalität muss man auch dort (wie bei den anderen auch) von Hand programmieren.
-
So, danke für alle Antworten bisher. Ich wollte mir jetzt demnächst ein Buch über GUI Programmierung kaufen. Aber ich hab keine Ahnung, was ich da nehmen soll. Qt, MFC? Braucht der Enduser für alle Sachen außer WinAPI ein Framework, bevor er das Programm starten kann (z.B. .NET)?
Gibt es einen Unterschied zwischen MFC und WindowsForms? Ist letzteres neu in der .NET Serie?
Ihr seht schon, dass ich von GUIs nicht sonderlich viel Ahnung habe. Es wäre also nett, wenn mit jemand eine kurze einfache Übersicht zur Hilfe erstellen könnte
Gruß, ph4nt0m
-
-
Wenn's Dir nur darum geht, unter Windows grafische Oberflächen zu programmieren, kannst Du auch erstmal nur mit dem Windows API programmieren, und Dir dazu das Buch von Petzold holen.
Das schöne daran ist, daß es ziemlich einfach geht, und daß man sehr schnell verstehen kann, wie das Fenstersystem unter Windows funktioniert.
Wenn Du den Windows API erst verstanden hast, wird es leichter, z.B. MFC zu benutzen.
Wenn's Dir darum geht, objektorientiert zu programmieren, sind sowohl der Windows API als auch MFC der falsche Weg. MFC war das erste C++ Projekt von Microsoft, und dementsprechend schlecht ist auch das Design. Daher, also für die objektorientierte GUI-Programmierung würde ich GTK oder QT empfehlen (wxWidgets in seiner aktuellen Version und FOX kenne ich nicht).
GTK arbeitet allerdings auch nach dem Wrapper-Prinzip: Das eigentliche Toolkit ist in C geschrieben, auf die ein C++-Layer aufgesetzt wurde. Dennoch ist es eigentlich ganz nett gemacht.
QT macht einen sehr einfachen und sehr sauberen Eindruck, jedoch habe ich noch nicht viel damit gemacht. Der QT Designer ist allerdings der beste, den ich je gesehen habe. "Mal schnell eine GUI machen" ist damit näher gerückt als mit anderen GUI-Buildern für C++.
-
Power Off schrieb:
Wenn's Dir nur darum geht, unter Windows grafische Oberflächen zu programmieren, kannst Du auch erstmal nur mit dem Windows API programmieren, und Dir dazu das Buch von Petzold holen.
Das schöne daran ist, daß es ziemlich einfach geht, und daß man sehr schnell verstehen kann, wie das Fenstersystem unter Windows funktioniert.
Also unter einfach verstehe Ich was anderes. Da ist GTK um Welten einfach zu handhaben.
Power Off schrieb:
GTK arbeitet allerdings auch nach dem Wrapper-Prinzip: Das eigentliche Toolkit ist in C geschrieben, auf die ein C++-Layer aufgesetzt wurde. Dennoch ist es eigentlich ganz nett gemacht.
Vielleicht verstehe Ich es auch falsch aber GTK ist das eigentliche Toolkit und in C geschrieben. GTKmm ist der C++ Wrapper mit dem es sich imo schön programmieren lässt. Leider ist das unter Windows (noch?) eine Qual..
Power Off schrieb:
QT macht einen sehr einfachen und sehr sauberen Eindruck, jedoch habe ich noch nicht viel damit gemacht. Der QT Designer ist allerdings der beste, den ich je gesehen habe. "Mal schnell eine GUI machen" ist damit näher gerückt als mit anderen GUI-Buildern für C++.
Jop, sehe Ich auch so.
Im Endeffekt würde Ich dir zu Qt raten. WinApi ist meiner Meinung nach _nicht_ leicht, zumindest ist es das im Vergleich zu Gtk, Qt,.. nicht. GTKmm finde Ich persönlich schöner als Qt aber unter Windows gibt's da afaik nur inoffiziele Pakete.
-
Finde rein vom Design her GTKmm auch schöner als QT (nur der Designer ist von QT halt um einiges besser, aber Glade2 ist auch schon ziemlich gut), allerdings ist es mir bis heute nicht gelungen meine erstellten GTKmm -Anwendungen zum laufen zu bekommen, da mein GTKmm Installer anscheinend ne falsche GTK+ Version installiert und daher nen paar Funktionen fehlen. Und wer sich mal GTK+ angeschaut hat weiß aus wievielen Bibliotheken das besteht (und für jede gibts dann noch nen C++ Wrapper bei GTKmm). Ist insgesamt also sehr Mühsam.
-
kann hier nur zustimmen und habe das schon oft geschrieben: GTK und GTKmm wird für Windows-Progger nicht supported. Kann man voll vergessen. Habe es auch noch nie zum Laufen bekommen. Die wollen das anscheinend auch nicht wirklich.
-
Artchi schrieb:
kann hier nur zustimmen und habe das schon oft geschrieben: GTK und GTKmm wird für Windows-Progger nicht supported. Kann man voll vergessen. Habe es auch noch nie zum Laufen bekommen. Die wollen das anscheinend auch nicht wirklich.
Das liegt eher daran, daß GNU und Linux mittlerweile so ineinander verzahnt sind, daß es kaum noch möglich ist, aus diesem Sumpf auszubrechen. Man braucht heutzutage sehr viele Programme und Libraries, um ein GNU-Projekt auf einem anderen Betriebssystem zu übersetzen. Z.B. GCC setzt mittlerweile voraus, daß bereits eine GCC installiert ist, was zu einigen Problemen führen kann. Auch die "gettext" Library, oder wie sie heißt, und noch etliche andere, komplizieren die Portierung von GTK.
Früher war das alles kein Problem.
Es wäre mit Sicherheit alles einfacher, wenn die GCC und die restlichen Bibliotheken auf einer virtuellen Maschine laufen würden, die ein minimales Systeminterface haben. So eine Mini-VM könnte dann leicht auf anderen Plattformen implementiert werden, und den Code ausführen (Beispiele: siehe INTCODE und Cintcode Engines von Martin Richards). Man könnte dann auch die Cross-Compiler-Funktionen der GCC ganz entfernen und die Systemspezifika (wie Prozessor etc.) an die VM delegieren.