Gibt es gute Alternativen zur MFC, oder sollte man lieber direkt bei WinAPI bleiben? Sprache: C++

berniebutt

Die WinApi besitzt eine reine C-Schnittstelle. Man muss Strukturen füllen, WinApi-Funktionen aufrufen, Nachrichten auswerten und ggfs. selbst senden. Ist heute eine Ochsentour, aber nahe an den Grundlagen jeder GUI. Nichst spricht gegen den Einsatz der WinApi aus einem in C++ geschriebenem Programm.

MFC und Borland haben etwas mehr Objektorientierung draufgesattelt. Der Resourcen-Editor und -Compiler der WinApi tun das aber auch recht gut. Will man mehr, wäre C# zu empfehlen. Dort wird alles mit Objekten, Eigenschaften, und Ereignisroutinen geregelt, was sehr übersichtlich ist. C# bietet allerdings zwei unterschiedliche GUIs: WindowsForms und WPF, wodurch die Einarbeitung etwas mühsam sein kann. Die anderen genannten GUI-Bibliotheken sind ähnlich.

Was du nun nehmen willst, musst du selbst entscheiden!

Beefi

Hi,

also vielen Dank an euch alle, für die vielen Tips. Ich hab ja auch seit dem letzten Post wieder nachgelesen und nachgedacht...die Sache mit einem Framework wäre schon besser für mich. Für spezielle Dinge kann ich ja immer noch auf die Windows-API greifen, so machte ich es ja auch zu VB6 Zeiten. Aber was die GUI und etwas Schnick Schnack drumherum betrifft, da bleib ich wohl doch bei der angenehmeren Methode, also einem ausgereiften Framework.
MFC fällt hier wegen der Lizenz schon mal raus und zu WTL bekomme ich kaum Information. Dann bleibt eigentlich nur noch wxWidgets.

Gut, viele Leser werden sich fragen, warum ich nicht einfach Qt nehme
Ich würde sehr gerne Qt nutzen, jedoch wage ich mich da aus folgenden Gründen nicht so ran:
Man sagt, dass es kein richtiges C++ sei sondern ein Mischmasch ähnlich wie C++/CLI. Also Qt hält sich angeblich nicht so wirklich an den Standard.
Dann gibt es da noch diesen Precompiler oder MOC...man hört, dass der selbstgeschriebene Code nicht direkt übersetzt wird, sondern durch einen Precompiler wieder verändert wird und das Ergebnis hiervon erst in Maschinencode kompiliert wird. Man weiß also nicht genau, wie das Programm überhaupt arbeitet, weil der eigene Code ja nicht der wirkliche ist.
Das sind keine Behauptungen von mir, das ließt man nur so im Internet. Ich hab schon oft versucht mehr Infos darüber rauszufinden...aber die Leute werfen immer nur diese Behauptungen in den Raum, ohne ausführlicher Erklärung wie das alles genau zu verstehen ist.

Auch dir Belli, danke für deine schöne Erklärung zu Win32++. Die PictureBox ist ein Steuerelement bei Visual Studio bzw. war es bei VB6 und ist es bei VB.NET. Im Grunde ist es nichts anderes als ein Steuerelement, was Bilder darstellen kann. Man kann auch darin Zeichnen, das Bild speichern usw. Eigentlich nichts besonderes, aber hätte ja sein können, dass man mit der WinAPI sowas erst selbst zusammenproggen muss...aber anscheinend kann man sich die ganzen fertigen Steuerelemente direkt über die API zusammensammeln

Beefi

So, also ich denke, dass das Thema als abgeschlossen gilt. Vielen Dank für die Tips und Anregungen.

Ich habe mir jetzt ein paar Frameworks/Toolkits in der Praxis angesehen. Also Library runtergeladen, kompiliert, Beispielprogramme kompiliert und etwas genauer unter die Lupe genommen...

wxWidgets:
So toll sich diese Lösung anhören mag, ein Einstieg für einen GUI-Anfänger kommt mir hier sehr schwer vor. Die unstable ließ sich mit MinGW wunderbar in der Konsole kompilieren. Die stable musste ich mit CMake in ein CodeBlocks Projekt wandeln und es aus der IDE kompilieren...ich weiß nicht warum, aber nur so gabs keine Compiler-Fehler
So, das war aber nur eine Kleinigkeit...war eigentlich easy. Nur die Einrichtung von wxWidgets war eine Hürde. Ich habe sämtliche Tutorials für CodeBlocks durchgearbeitet, dauernd kommt irgendein Fehler oder wird irgendwas nicht gefunden. Obwohl die Umgebungsvariablen in Windows und CodeBlocks korrekt eingerichtet waren (auch der Rest in CodeBlocks), hab ich einfach kein Beispielprogramm zum Laufen bekommen. Ich konnte nicht mal ein leeres Fenster mit dem Wizard des eingebauten wxSmiths erstellen
Nach ein paar Stunden habe ich es dann aufgegeben und mich FLTK zugewendet.

FLTK:
Absolut Top! Sehr leicht anzuwenden und sehr leicht zu lernen! Auch die Dokumentation finde ich Traumhaft. Man kann sie als PDF runterladen und hat quasi direkt ein Lernbuch zum GUI-Toolkit. Bei anderen Toolkits muss man sich oft durch verstreute online Dokus durchkämpfen.
So leicht, schnell und schlank FLTK auch ist, schreckte mich jedoch das Design etwas ab. Klar kann man es teilweise auch ändern (zB Plastic-Theme), jedoch werden hier nicht alle Steuerelemente verändert. Man hat dann einen Misch-Masch aus modernen Plastc-Buttons und Windows95-ComboBoxen. So sollte man allgemein eher bei dem Windows 95 Design bleiben, damit alles wie aus einem Guss aussieht. Das wäre soweit schon noch in Ordnung für so ein tolles Toolkit, aber das Menü ist dann noch die Spitze vom Eisberg. Dieses Design passt absolut nicht in Windows und würde wahrscheinlich jeden User so abschrecken, immer eine Alternative zum jeweiligen Programm zu suchen Es ist aber nicht nur das Design, sondern auch die Bedienung und das Verhalten. Ich glaube, auf meinem alten Amiga aus den 80ern mit Workbench war das Menü schon angenehmer.
Das soll aber allgemein nichts negatives zu FLTK sein...FLTK hat eben seinen bestimmten Einsatzzweck. Nur das Design entspricht in manchen Punkten nicht mehr meinem persönlichen Geschmack.

Ultimate++:
Es ist einfach super. Die Bibliothek scheint leicht erlernbar zu sein und die Anwendung ist absolut unkompliziert. Man kann die Lib pur benutzen oder die mitgelieferte IDE verwenden. Die IDE+Library wirkt auf mich wie ein voll ausgerüstetes Visual Studio, mit welchem man leicht Anwendungen für mehrere Betriebssysteme erstellen kann. Und damit meine ich eine wirkliche Alternative zu Visual C++ & MFC. Die hier erstellten Programme haben absolut nativen Windows Look und haben auf jeder Windowsversion das entsprechende Design. Abgesehen davon kann man das Design auch zur Laufzeit ändern...zB diesen OfficeXP-Stil, oder Office2003, oder Linux, usw.
Hier funktionierte einfach alles auf anhieb. Ich habe die Beispielprogramme mit MinGW übersetzt (es gibt auch Unterstützung für MS VC++).
Wie die erstellten Programme unter Linux umgesetzt werden, konnte ich aber nicht herausfinden. Optisch wirkt ein mit Ultimate++ erstelltes Programm unter Linux für mich wie als wäre es mit Qt geschrieben.
Achja, und die Ausführungsgeschwindigkeit ist extrem schnell...mir kommt es sogar flotter als FLTK vor

Qt:
So, trotz der Präprozessor-Sache werde ich es noch als nächstes Testen. Immerhin ist es ja die Eierlegende Wollmilchsau.

Fazit:
Wahrscheinlich werde ich mich für Qt entscheiden, weil es so abgekapselt und simpel ist, dass man normalerweise nicht mal in Spezialfällen auf die Windows-API greifen muss. Auch lege ich viel Wert auf eine gute Dokumentation, welche hier ja sehr gut sein soll. Von Qt zurückgehalten hat mich eigentlich immer nur der Präprozessor (MOC) und eben die angebliche langsame Ausführungsgeschwindigkeit (relativ zu anderen Frameworks). Aber davon muss ich mir jetzt abend selbst ein Bild machen. Ansonsten wäre Ultimate++ mein klarer Favorit.

Vielleicht hilft dieser Thread ja dem einen oder anderen, der mit der GUI-Programmierung anfangen will. Ist jetzt nur schade, dass sich das so entwickelt hat, dass es eigentlich gar nichts mehr mit der WinAPI-Programmierung zu tun hat. Vielleicht sollte man dieses Thema in "Andere GUIs" verschieben?

Mechanics

Beefi schrieb:

Von Qt zurückgehalten hat mich eigentlich immer nur der Präprozessor (MOC) und eben die angebliche langsame Ausführungsgeschwindigkeit (relativ zu anderen Frameworks).

Wir benutzen in der Arbeit Qt. Der MOC stört keinen. Es mag kein reines C++ sein, aber es stört keinen und im Endeffekt gehts in der Arbeit meist um ganz andere Aspekte und nicht um irgendwelche Glaubenskriege.
"Langsam" ist es auch nicht. Es ist ein GUI Framework, was soll daran langsam sein. Merkst du einen Unterschied, ob ein Knopf in einer Nanosekunde oder in 1,2 Nanosekunden aufgebaut wird?

Beefi

Wir benutzen in der Arbeit Qt. Der MOC stört keinen.

Ich denke auch, dass er mich nicht stören wird. Ist ja eigentlich egal was beim kompilieren passiert, wenns richtig gemacht wird und funktioniert.
Darum machte ich mir auch nicht so großen Sorgen. Mich beunruhigten hier eher Erfahrungen von Leuten die berichteten, dass der MOC manchmal Probleme machte, und beim richtigen Kompilieren Fehler auftraten. Es ist hier sehr schwer den Fehler zu finden, da er nicht wirklich im eigenen Code ist, sondern im "Zwischencode" den der MOC "falsch" umgesetzt hat.
Aber wie gesagt, dass habe ich nur des Öfteren so gelesen und basiert nicht auf eigenen Erfahrungen

Es mag kein reines C++ sein, aber es stört keinen und im Endeffekt gehts in der Arbeit meist um ganz andere Aspekte und nicht um irgendwelche Glaubenskriege.

Ja ich weiß schon, dass bezüglich der Softwareproduktion in Firmen andere Verlangen gelten. Z.B. schnell und einfach ans Ziel zu kommen (wie es ja mit .NET der Fall ist). Der Rest interessiert nicht so besonders, da ja die Rechner immer Leistungsstärker werden.
Wenn ich jedoch Privat als Hobby programmiere, bin ich eher der Typ, der auf schlanke und flotte Sachen steht
Mein "Hello World"-Programm, welches ich heute mit Qt kompiliert hatte, war glaub ich um die 40 MB groß
Aber ja, das sind eben die DLLs.

"Langsam" ist es auch nicht. Es ist ein GUI Framework, was soll daran langsam sein. Merkst du einen Unterschied, ob ein Knopf in einer Nanosekunde oder in 1,2 Nanosekunden aufgebaut wird?

Nein, das merke ich nicht Ich meinte da eher die Auslastung, wie der Rechner damit fertig wird...das addiert sich ja alles zam. Wie zB bei KDE...ist ja auch nicht so der Click-Reaktionsmeister. Kann aber auch daran liegen, weil es allgemein so aufgebläht ist und die Schuld nicht an den Qt-Libs selbst liegt.
Wo ich jedoch hier schon bei den Beispielprogrammen einen Unterschied merke, ist die Ladezeit der Programme. Die Beispiele von Ultimate++ gehen unmittelbar nach dem Klick auf und sind voll geladen...selbst große und komplexe Programme (da sind ja ganz schön heftige Dinger dabei)...wie ein Hello World in der Konsole
Bei Qt dauert das ganze schon länger, selbst bei kleinen Beispielen. Vielleicht kommts auch nur davon, weil für ein "Hello World" erstmal 100 MB in den RAM geladen werden müssen

Aber Qt macht schon einen guten Eindruck, werde mich da parallel zu Ultimate++ Schritt für Schritt einarbeiten und irgendwann lasse ich dann eines der beiden Frameworks links liegen.
Aber Ultimate++ ist schon eher das, was ich zu Anfang des Threads suchte. Die IDE und das ganze Drum herum gefällt mir hier schon mal besser als bei Qt und dem QTCreator.

Mechanics

Beefi schrieb:

Es ist hier sehr schwer den Fehler zu finden, da er nicht wirklich im eigenen Code ist, sondern im "Zwischencode" den der MOC "falsch" umgesetzt hat.

Das passiert nicht. Vielleicht kommen diese "Erfahrungsberichte" von Leuten, die es das letzte mal mit einer pre-alpha von Qt 0.1 ausprobiert haben. Es ist ein ausgereiftes Framework, das von großen Firmen für große Projekte verwendet wird.

Beefi schrieb:

Z.B. schnell und einfach ans Ziel zu kommen

Nicht unbedingt und nicht unbedingt nur das. Oft ist auch wichtig, wie gut der Code wartbar und erweiterbar ist. Unsere Software wird seit mittlerweile 20 Jahren entwickelt, da ist "schnell ans Ziel kommen" gar nicht mal mehr so wahnsinnig wichtig. Aber wir haben auch recht viel GUI und die ist vielfältig und komplex und muss in verschiedenen Umgebungen funktionieren, z.B. als Plugin in einem CAD System. Du kannst dir nicht vorstellen, was für Probleme wir im Laufe der Zeit schon alles hatten. Und die GUI wird immer komplexer, es kommen immer mehr Anforderungen, weil man immer mehr Daten darstellen und verknüpfen muss, aber ohne dass es langsamer wird oder die Eingaben zu komplex werden. Da sind wir mit unserem letzten Framework gegen die Wand gefahren, mit Qt sind wir recht zufrieden.

Ja, die Qt ist recht groß und braucht ein bisschen zum Laden... Spielt bei der größerer unserer Software überhaupt keine Rolle mehr Aber wenn du nur was kleines schreiben willst und keine besondere Features brauchst, spricht auch nichts dagegen, ein kleines leichtgewichtiges Framework zu nehmen. Ich versuche dir nicht die Qt anzudrehen, ich will dir nur die ganzen Vorurteile ausreden.

Ich mag bei Qt die signals & slots, wie ist es denn bei U++?

Beefi

Das passiert nicht. Vielleicht kommen diese "Erfahrungsberichte" von Leuten, die es das letzte mal mit einer pre-alpha von Qt 0.1 ausprobiert haben.

Ja, so wird's wohl sein. Dachte auch, dass es vielleicht Leute sind, die so fest von ihrem Framework besessen sind, nichts anderes mehr (und vor allem Qt) zu akzeptieren
Ich denke Qt wäre nicht so beliebt, wenn es hier dauernd Probleme gäbe.

Oft ist auch wichtig, wie gut der Code wartbar und erweiterbar ist.

Ah da fällt mir jetzt noch ein Gerücht ein Ich hab auch schon ein paar mal gelesen, wie sich Leute beschwerten, dass Qt nicht für größere Projekte geeignet sei, da es sehr unübersichtlich und nicht mehr zu warten wird. Und eher für kleine bis mittelgroße Dinge brauchbar ist...vielleicht begründeten sie es noch mit der Geschwindigkeit, ich weiß es nicht mehr. Ich konnte aber nie verstehen warum...Qt ist doch so simpel, dann müsste es ja erst recht für große Projekte gut sein, weil man besser den Überblick behält

@Hi:

Ich mag bei Qt die signals & slots, wie ist es denn bei U++?

Ich bin noch eher am erforschen der Features des Frameworks, was es so kann und wie es das kann. Aber so wie ich das sehe, werden Callbacks verwendet. Ist aber auch sehr simpel...das ganze Framework scheint so easy wie Visual Basic zu sein Es gibt auch Code-Vergleiche, wo man die gleichen Projekte mit verschiedenen Frameworks umsetzte. Hier hat Ultimate++ nur etwa ein drittel des Codes wie bei Qt. Und man sieht auch sofort am Code, dass Ultimate++ nochmal um einiges leichter ist, als sogar Qt...nach meinem Empfinden.

Hier ein Code-Vegleich:
[http://www.ultimatepp.org/www $uppweb$ vsqt $en-us.html](http://www.ultimatepp.org/www$ uppweb $vsqt$ en-us.html)

Hier ein Abschnitt aus der Dokumentation, wie simpel man GUIs erstellt:
[http://www.ultimatepp.org/srcdoc $CtrlLib$ Tutorial $en-us.html](http://www.ultimatepp.org/srcdoc$ CtrlLib $Tutorial$ en-us.html)
Im Punkt 2 sieht man, wie simpel man ein Fenster erstellt...man deklariert es einfach wie eine Variable und schon ist es da.
Im Punkt 3 sieht man, wie man dann noch die benutzerdefinierte Größe festlegen kann.
Usw usw...
Ich muss ehrlich sagen, dass ich mich bei den ganzen Frameworks noch nicht so intensiv mit dem Code beschäftigt habe, sondern eher die Features. Aber für mich ist das Visual Basic pur Ich kann mir nicht vorstellen, wie man es noch einfacher machen kann. Wie es bei Qt umgesetzt ist, weiß ich noch nicht.
Natürlich kann man das ganze auch mit dem integrierten GUI Designer machen, Bild/Icon-Editor und solche Sachen sind auch mit in der IDE.

Was mich grad etwas beschäftigt, ist das Design der GUI...da steckt was ganz interessantes dahinter. Es ist ja ein Crossplattform-Framework...aber ich konnte noch nicht herausfinden, was es unter Linux benutzt (zb GTK oder Qt ?).
Nun hab ich mal auf meinem sowieso unbenutzten Netbook Linux installiert (XFCE). Die IDE und auch die mit Ultimate++ erstellten Programme, haben hier exakt das GTK Design. Ändert man allgemein das GTK-Design in XFCE, so wird es auch in den U++ Programmen direkt mit verändert.
Sprich: es verhält sich wie GTK.
Fakt: Es ist aber kein GTK. Es braucht auch keine GTK oder Qt Libs, sondern nur X11-Libs.
Um es genau zu wissen, wird jetzt dann KDE installiert, ob hier die Programme auch wie alle anderen Qt Programme aussehen

Ich sagte zwar anfangs, dass ich nur was für Windows suche, aber das hat mich jetzt schon interessiert. Angeblich soll das unter Mac OSX auch so sein.
Diese "Style-Engine" nennt sich bei Ultimate++ Chameleon und laut Doku/Forum sollen die Programme immer nativ dem entsprechendem System aussehen.
Man kann das Design aber auch von "Host Platform" auf andere ändern.
Auch der schon angesprochene OfficeXP/Office2003 Look ist unter Linux möglich. Aber nicht etwa so wie manche Windows-Themes von GTK/Qt, sondern es sieht EXAKT wie ein Windows Programm aus.
Ich frage mich, wie die das machen...vor allem ist das ganze auch noch wirklich flott. Die alte Netbook-Kiste mit Atom-Prozessor ist sehr pingelich, aber die U++ Programme flitzen wie als wäre Windows 95 drauf
Allein die IDE (welche schon sehr komplex ist) startet so schnell, dass man sagen könnte, dass hier wirklich nur noch die Festplatte begrenzt. Die IDE startet hier auch nicht langsamer, als auf meinem modernen i5-Notebook.

So jetzt Schluss mit der Schwärmerei

EDIT:
So kurzer Nachtrag...
Also auch unter Kubuntu, hat es den exakten Qt-Stil. Wenn man ein Programm schreibt, muss man es also nur für Linux kompilieren und fertig. Es hat immer den exakten Stil wie das Betriebssystem und verhält sich auch so. Auch wenn man im Betrieb das Theme des Systems ändert.
Da man mit der Ultimate++ Lizenz auch kommerziell statisch linken darf (BSD-Lizenz), ist das voreingestellt. Im Framework ist auch alles enthalten was man braucht (Netzwerk, OpenGL, und und und). Man kompiliert also eine einzige ausführbare Datei und kann diese verteilen. Keine Umwege mit "./configure, make, make install" oder irgendwelchen Paketen. Nur Datei anklicken, und egal unter welcher Oberfläche, es läuft und man kann absolut nicht erkennen, ob es mit GTK oder Qt geschrieben ist, weil es das auch nicht ist, aber trotzdem irgendwie so scheint
Es sei betont, dass man hier auch nichts zur Kompilierzeit beachten muss, welche "Ziel-Oberfläche" das Programm haben soll. Man kann die gleiche ausführbare Datei sowohl unter Gnome, XFCE, KDE, usw ausführen und es sieht immer aus wie das System selbst und ändert sich auch beim Theme-Wechsel mit. Ich habe aber keine Ahnung, wie die das machen.
Auch die Windows/Office Styles können zur Laufzeit geändert werden und man muss nichts beim Kompilieren beachten.

Ich habe auch noch einen Foren-Eintrag gefunden, dass es tatsächlich alles direkt auf X11 basiert. Man kann aber seit neuestem direkt für GTK-Kompilieren, wie GTKmm (wenn ich das richtig verstanden habe). Muss man aber nicht.
Hier der Link: http://www.ultimatepp.org/forum/index.php?t=msg&goto=38663&

Bitte korrigiert mich, falls ich mich bei etwas vertan habe. Vor allem bei der Lizenz. Ist es korrekt, dass man mit der BSD Lizenz statisch linken darf und das Produkt auch kommerziell vertreiben darf?

Beefi

Falls es jemanden interessiert, wie das ganze aussieht, habe ich mal ein paar Beispielprogramme kompiliert.
Es handelt sich jeweils um eine Datei, die direkt ausführbar sein sollte, also keine weiteren Linux-Pakete, Librarys, oder sonst was.

Es ist eine ZIP-Datei in der drei Ordner sind:
Windows: Kompiliert unter Windows 7 x64 (sollte aber ein 32-Bit Programm sein)
Linux_x32: Kompiliert unter Lubuntu 13.04 32-Bit Live-CD
Linux_x64: Kompiliert unter Lubuntu 12.04 64-Bit Live-CD

Bei den Linux-Versionen muss man eventuell noch mit Rechtsklick drauf -> Eigenschaften und Datei ausführbar machen.
Oder eben das ganze entsprechend in der Konsole.

Ich wusste nicht wie/ob man hier Dateien hochladen kann, deshalb ein FileHoster...wenn man auf den Link klickt, erscheinen mehrere Download-Buttons. Der unauffälligste führt zum Ziel

Die Programme wurden nicht von mir verändert, es sind die originalen, die mit der IDE ausgeliefert werden. Einfach nur geöffnet und kompilert. Wenn man die IDE installiert, gibt es noch sehr viel weitere Beispiele.

Das Programm "AddressBook" ist das Qt-Vergleichsprogramm, welches auch in einem Link zu Ultimate++ in einem meiner vorherigen Posts gezeigt wird. Die Qt-Variante kann man im QtCreator laden und kompilieren.

Download: http://www.file-upload.net/download-7748422/Upp-Tests.zip.html

Mechanics

Was mir noch einfällt: Beefi muss mit

Beefi schrieb:

Ich hab auch schon ein paar mal gelesen, wie sich Leute beschwerten, dass Qt nicht für größere Projekte geeignet sei, da es sehr unübersichtlich und nicht mehr zu warten wird.

Man stößt durchaus auch bei Qt an die Grenzen des Frameworks, so ist es nicht. Aber z.B. Maya verwendet Qt für die GUI und wieviel umfangreicher kann ein Projekt schon werden?
Dass es unübersichtlich ist, kann ich nicht bestätigen. Allein durch das in die Sprache mit eingebaute MVC Konzept mit den Modellen für die GUI erzwingt es schon mehr oder weniger einen halbwegs sauberen Stil. Und es ist alles recht gut gekapselt. Kein Vergleich zu Frameworks ala MFC, wobei MFC sogar auch schon sowas wie MVC hatte mit den Document/View Klassen.
Wartbar ist es auch... Wir haben schon einiges in Qt selber umgebaut/erweitert/angepasst, weil man wie gesagt auch damit an die Grenzen stößt.

Ich hab diesen Vergleich zwischen Qt und Ultimate++ angeschaut und seh ehrlich gesagt nicht, warum der Code bei Ultimate++ kürzer ist. Was mir auffällt ist, dass der Qt Code verdächtig nach Qt 3 ausschaut. Ich habs mir nicht genau angeschaut, aber ich seh keinen Grund, warum der Qt Code länger sein sollte. Wahrscheinlich ist der Vergleich nicht ganz fair.

Wenn man sich den Qt source ansieht, vergehts einem aber auch gewaltig
Ist das bei allen größeren open source Projekten so? Einfach nur noch schwerstes Gefrickel...

Mechanics

Ich weiß nicht, was du hast Es ist bei allen Open Source Projekten, die ich gesehen habe, wesentlich schlimmer. Qt ist jetzt nicht übertrieben schön oder elegant, aber es ist sauber und konsistent. Alle größeren Open Source Projekte, die ich gesehen habe, sind im Vergleich dazu echt übel.

Beefi

Was mir auffällt ist, dass der Qt Code verdächtig nach Qt 3 ausschaut. Ich habs mir nicht genau angeschaut, aber ich seh keinen Grund, warum der Qt Code länger sein sollte. Wahrscheinlich ist der Vergleich nicht ganz fair.

Ja das mit Qt3 kann sogar sein...die Beispiele haben auch noch Windows XP Oberfläche. Wobei Windows XP ja noch nicht ganz tot ist
Wenn man sich den Vergleich ansieht, haben sie es unten auch nochmal etwas geändert, um es fairer Qt gegenüber zu machen. Aber ich kann damit eh nicht viel anfangen, weil ich Qt ja nicht kenne.

Was mir jedoch sofort an den Ultimate++ Codebeispielen auffiel, es ist bei weitem nicht so kompliziert wie wxWidgets und GTKmm Auf den ersten Eindruck zumindest.

Es ist bei allen Open Source Projekten, die ich gesehen habe, wesentlich schlimmer.

Ihr meint jetzt den Sourcecode von Qt selbst?
Hab ich auch schon oft gehört, dass Open Source Projekte im Code meist fürchterlich aussehen. Auch der Linux Kernel soll der größte Saustall sein
Aber Qt ist ja noch nicht sooo lange Open Source...das stell ich mir noch recht sauber vor

Mechanics

Ich hab nochmal drübergeschaut... Bin immer noch zu faul, mich da wirklich reinzudenken, halte den Vergleich aber immer noch nicht für fair Was soll z.B. diese riesenlange findEntries Methode in der Qt Version, wo sie auf der anderen Seite nur eine paar Zeilen lange Search Methode haben? Das kann man alles so direkt nicht vergleichen, außerdem würde man das so wahrscheinlich eh nie implementieren. In Qt würde man fürs Suchen am ehesten ein Proxy Model verwenden, dann wärs vielleicht eine Zeile, den Suchbegriff zu setzen. Oder man braucht da noch irgendwelche Optionen (nach was genau man sucht), dann würde man vielleicht vom Proxy Model ableiten und eine Methode überschreiben. Wär etwas Boilerplate, aber sauber und wahrscheinlich immer noch kürzer als das was sie da gemacht haben. Und überhaupt würde man die Suche wohl eher auf dem richtigen Datenmodell machen und nicht auf der GUI Zwischenschicht.

Beefi

Hi,

der Qt-Code ist von den Qt-Entwicklern höchst persönlich
Das Beispiel ist auch im QtCreator bereits zum testen enthalten.
Die Ultimate++ Entwickler haben es dann nur mit Ihrem FrameWork realisiert.
Wenn man auf der Startseite im Creator oben rechts auf Beispiele klickt, müsste es dabei sein.

Mechanics

Mag sein, ist aber nicht die beste Implementierung und veraltet. Ist irgendwie schwer, sowas sinnvoll zu vergleichen.
Worauf ich hinaus will ist, dass ich generell nicht sehr viel Potenziall sehe, dass bei einem GUI Framework deutlich weniger Code rauskommen würde. Die sind sich doch alle zu ähnlich und viel Boilerplate braucht man bei Qt nicht, von dem her wirst du in der Praxis bei beiden Frameworks ähnlich viel Code brauchen. Und wenn du dein Programm sauber aufbaust, wirst du tendenziell etwas mehr Code brauchen.

Guten Abend,
erstmal großen Dank an den Thread Ersteller ich suche schon seit 1 Woche nach so einem Thread.
Es ist erstaunlich wie ähnlich sich deine Anschauung und Vorgehensweise mit der meinen decken. Auch dein Beruf und dein Hobby. Irgendwie erschreckend, sind wir alle doch nur in einer MATRIX?
Wie erwähnt habe ich im Grunde den gleichen Weg auf der GUI lib Suche hingelegt, und bin bei Qt und WxWidgets hängen geblieben. Ich verstehe nicht wie du Probleme beim compilieren der WxWidgets Programme gescheitert bist. Ich habe mir Codilite runtergeladen und einfach drauf los compiliert- ohne irgenwas einzustellen.
Von Ultimate++ habe ich heute zum ersten mal gelesen und ich bin dir dankbar das du es so ausführlich beschrieben hast. Ich werde es mir gleich anschauen - wxWidgets ist zwar sehr nett aber irgendwie sehne ich mich insgeheim nach etwas schlankerem- etwas Kompakterem, und genau das Scheint mir nach deiner Beschreibung Ultimate++ zu sein. Was mich noch interessieren würde ist, wie gut es mit anderen IDEs ausser der ihren zusammenarbeitet. Du hast nur kurz erwähnt das es auch mit VS funktioniert. Gibt es ein AddIn für VS.
Aufjedenfall danke für deinen Beitrag- das Internet ist inzwischen so voll von Müll das man nur sehr mühsam an echte und brauchbare infos kommt, vor allem als anfänger.
Gruß.

Beefi

Hi Ghost++,

bei wxWidgets hatte ich mit CodeBlocks irgendwie Probleme, dass die IDE/Compiler irgendwie nicht alle Bibliotheken richtig gefunden hat. Ich habe sämtliche Tutorials durchgemacht, aber es gab beim Kompilieren trotzdem immer Fehlermeldungen...obwohl der Vorgang eigentlich sehr simpel ist und nicht anders als bei anderen Bibliotheken. Das war bestimmt nur ein kleiner Fehler, den ich irgendwo übersehen hatte.
Was wxWidgets betrifft habe ich für mich jedoch folgende Alternative gefunden...
Unter Windows: Win32++
Unter Linux: GTKmm
Win32++ ist absolut easy zu lernen und macht dir ein kleines flottes Programm. Es ist quasi wie direkte Win32API-Programmierung, jedoch wie die MFC gekapselt...Nur eben kostenlos und viel einfacher.
GTKmm ist die C++-Variante von GTK+ und fast schon Standard auf Linux. Und sehr flott (auch bei leistungsschwachen Geräten). Wenn man auf der Spielwiese Linux mitmischen will, ist das eine gute Wahl, weil vieles mit dem Toolkit geschrieben ist...kannst also Programme für eigenen Zweck umschreiben usw.

Diese beiden Lösungen sind jetzt eher nur für die GUI (wobei Win32++ noch mehr zu bieten hat, Netzwerk usw.). Klar denken sich viele, dass man das mit Qt auch abdecken kann, aber Qt trifft einfach nicht meinen persönlichen Geschmack. Das sind mehrere Faktoren...diese hunderte von MB die man immer installieren muss, die geringere Performance im Vergleich zu Win32++ oder GTK, MOC, große Bibliotheken, Bibliotheken nicht statisch linkbar, usw.
Und ich brauche zu den beiden oben genannten Bibliotheken kaum was. Is ja schon fast alles in der Standardlibrary drin...und für ein paar andere Kleinigkeiten kann man ja ne andere Bibliothek suchen, zB Boost für Netzwerk usw. Das ganze kann/darf man dann oft auch noch statisch reinlinken.

Ja und Ultimate++ ist hier eben (für mich) die eierlegende Wollmichsau. Wenn man sich ansieht, was hier alles im Toolkit enthalten ist, vermisst wohl kaum jemand etwas. Es ist alles absolut frei und auch noch kommerziell nutzbar...und eben statisch linkbar. Ultimate++ ist eigentlich sogar eher zum statisch linken gedacht...man kann aber auch dynamisch linken.
Und was hier genial ist: Du musst am Code wirklich GAR NICHTS ändern, wenn du das gleiche Programm für Linux und Windows kompilieren willst. Bei wxWidgets ließt man oft von frickeleien...und von Qt auch manchmal. Diese Beispielprogramme, die ich hier im Thread angehängt habe, laufen auf jeder Linux-Kiste. Selbst wenn du nur Xorg installiert hast und sonst nichts. Und es ist auch kein Problem, diese Programme ohne Anpassungen auf meinen Raspberry zu spielen
Du hast mich nach anderen IDEs in Zusammenhang mit dieser Bibliothek gefragt...es geht...ich habe es mit CodeBlocks und VS2012 Express probiert. Man hat aber mehr Vorteile, wenn man die IDE von denen verwendet (hier sind echt gute Techniken eingebaut, vor allem in Kombination mit der Library).

Für mich ist/war CodeBlocks immer die beste IDE. Ich installiere mir Visual Studio nur, wenn ich wirklich abhängig von C#/VB.NET bin. Ein was stört mich nur an CodeBlocks und zwar ist das beim Debuggen der Inhalt der Variablen. Die muss man extra immer mit diesem Watch-Fenster angeben...und wenn man das macht, tauchen manchmal aus heiterem Himmel Programm-Fehler auf (Segmentation Fault) die man nur lösen kann, indem man den Wert der Variablen nicht mehr kontrolliert (absoluter Schwachsinn und nicht Sinn beim Debuggen). Ich hab schon etliche Zeit mit der Suche nach irgendwelchen Code-Fehlern verbracht, wo ich wohl welchen Fehler gemacht hab...obwohl der Fehler nur vom Debuggen entstand.
TheIDE (IDE von Ultimate++) hat ein neues Debugger-Interface...echt hammer gemacht (gefällt mir besser als bei Visual Studio). Hier kann man zB auch ganz locker mit dem Mauszeiger über ne Variable fahren und der Wert wird angezeigt.
Die Code-Vervollständigung ist bei TheIDE nur "noch" nicht ganz so toll, wie bei CodeBlocks. Es ist sehr schwer, sich zwischen den beiden zu entscheiden. Beide IDEs sind wirklich verdammt gut. Aber Visual Studio fliegt wieder von meinem PC...ich brauche diese ewigen Softwarepakete nicht alle, nur um ein einfaches C++ Programm zu schreiben. Hatte es nur für schnelle GUI-Programmierung in VB.NET genutzt. Ich will eh immer nen schnellen PC, aber nach Visual Studio Installation, bootet der Rechner dreimal so lange

Dann kann ich dir noch folgenden Tip geben (da wird es aber auch verschiedene Meinungen geben). Wenn du ab und zu unter Linux programmierst, dann bleib auch bei Windows beim GNU GCC (also MinGW). Ich habe auch erst unter Windows mit VS gearbeitet und unter Linux mit GNU GCC. Die Compiler sind aber unterschiedlich...der eine meckert, wo es der andere nicht macht...und umgekehrt. Man muss sich auf seinen Compiler einfach einleben. Wenn ich die einfachsten Konsolenprogramme unter Visual Studio kompilieren will, steht oft erstmal ne neue Fehlersuche an...obwohl unter MinGW alles bestens war
Das liegt aber manchmal auch nur an Einstellungen.

knivil

Ja und Ultimate++ ist hier eben (für mich) die eierlegende Wollmichsau. Wenn man sich ansieht, was hier alles im Toolkit enthalten ist, vermisst wohl kaum jemand etwas.

Genau das ist das Problem. Ich will beispielsweise keine Threads, da die Standardbibliothek von C++11 das viel besser handhabt.

Beefi

Das kapier ich nicht so ganz. Was meinst du genau?