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

Beefi

Versteh ich nicht...dies geht genauso mit asm oder C.

Ja geht eigentlich schon, ist aber nicht mehr so gefragt bzw. nicht mehr so der aktuelle Stand. Man könnte bestimmt auch jedes Windows-Programm in Assembler schreiben, macht man aber nicht, da es sich nicht so wirklich rentiert (außer eben bei kritischen Systemdingen).
Assembler und C ist ja nicht weg von der Fläche, aber als Elektroingenieur kommt man um C++ nicht mehr herum.

knivil

Fuer einfache GUIßProgramme benutye ich die Bibliothek fltk. Sie ist sowohl fuer Linux als auch Windows verfuegbar.

Beefi

Fuer einfache GUIßProgramme benutye ich die Bibliothek fltk. Sie ist sowohl fuer Linux als auch Windows verfuegbar.

Ja FLTK scheint echt super zu sein...das wäre eigentlich auch mein Favorit gewesen. Aber ich denke, ich bleibe jetzt echt erstmal bei der WinAPI und danach evtl "Frameworks" wie Win32++ oder Ultimate++.

Ich fand FLTK auch erst angenehm, weil es auch unter Linux läuft, aber ich bin seit ner Weile wieder fest zu Windows zurück. Ich setze fest auf Windows und um hier die Hintergründe besser zu verstehen, wird die WinAPI wohl das beste für mich sein.

Wenn ich nach Büchern zur WinAPI suchte, wurde oft der Klassiker von Charles Petzold empfohlen. Das Buch ist ja immerhin schon vom Jahr 2000. Ändert sich an der WinAPI denn gar nichts? Sollte ich jetzt nach fast 14 Jahren immer noch dieses Buch studieren, oder habt ihr noch andere Empfehlungen? Ein eBook als HTML oder PDF wäre auch super, falls es sowas gibt.

Mechanics

Beefi schrieb:

ich bleibe jetzt echt erstmal bei der WinAPI

Das bringt irgendwie nichts... Ich glaube wirklich nicht, dass irgendjemand tatsächlich GUIs mit der WinApi erstellt. Es gibt nichtmal Layouts, was fast schon unverzichtbar ist. Es ist sehr aufwändig und es gibt damit nur lauter Probleme, die keinen interessieren und es ist praktisch unmöglich, irgendwelche fortgeschrittenen Features einzubauen. Die ganze GUI Programmierung an sich ist doch ziemlich nebensächlich. Das will man möglichst schnell und problemlos erledigen. Dabei kommen aber öfter aber irgendwelche Ideen wie "wär doch nett hier noch...". Geht aber nicht mit der WinApi, muss man erstmal tagelang programmieren und debuggen, wo die größeren Frameworks schon das meiste erschlagen würden. Du wirst wohl kaum einen Arbeitgeber finden der sagt, klar, nimm WinApi und schreib eine GUI.

Beefi

Ja wie gesagt, ich bin offen für Empfehlungen.
Es wird nur sehr sehr oft empfohlen, mit der WinAPI zu beginnen.
Ich hab zich Jahre mit VB6 programmiert und kam super zurecht damit...und es ging alles schnell. Auch hier hab ich in manchen fällen auf die Windows API-Funktionen zurückgegriffen. Im großen und ganzen musste ich mich jedoch um die GUI gar nicht kümmern. Ich weiß, dass VB6 keinen guten Ruf...ich will damit nur sagen, dass ich gerne auf solche Programmierhilfen zurückgreife.
Es soll aber schon eher ein Microsoft-Ding sein...bzw ne richtige Windows-Sache.
Und das ist in Verbindung mit Visual C++ eben die MFC. Über die MFC wird auch oft geschimpft, aber das ist eben ein offizieller Weg der Windows-Programmierung mit C++. Nur leider möchte ich nur die VS Express Version für mein Hobby nutzen. Deswegen kam ja ursprünglich die Frage zu einer Alternative...ich hörte da schon von WTL, Win32++ usw. Wollte jedoch eure Meinung dazu hören. Mit Visual Basic musste ich mir über solche Dinge ja nie Gedanken machen und C/C++ kenne ich nur in Verbindung mit Konsolenanwendungen.

Mit "richtiger Windows-Sache" meine ich natürlich auch solche Frameworks/Toolkits wie eben Win32++, weil es auf die WinAPI zurückgreift und native Windows-Anwendungen erstellt. Es soll nur nicht sowas wie Qt oder GTK sein...die Programme werden nie Linux als Ziel haben. Und auch wenn Qt auch rein für Windows empfohlen wird, ist es für mich eben keine richtige Windowsanwendung.

Ich stelle mir die MFC so vor, dass sie alles abdeckt und man nur in extremsten Ausnahmefällen direkt eine Windows-API-Funktion einbinden muss. Gibt es hier kostenlose Alternativen, oder sind Frameworks wie Win32++ nur für simple GUIs und den Rest muss man dann sowieso wieder über die API machen?

Mechanics

Keine Ahnung, wie du dir das alles vorstellst... Wenn du schon weisst (wie anfangs geschrieben), dass du nur ganz simple GUIs brauchen wirst, dann nimm sowas wie WTL oder Win32++ oder ähnliches. Aber wenn du irgendwo arbeiten willst, wird dir dein Arbeitgeber wahrscheinlich vorschreiben, was du zu benutzen hast (außer es ist eine kleine Firma und es ist ein ganz neues Projekt und du darfst frei entscheiden). Und die meisten GUIs werden irgendwann mehr oder weniger zwangsläufig komplexer. Mit komplexeren Frameworks kann man oft mit sehr wenig Aufwand Features einbauen, die dem Kunden einen gewissen Mehrwert bieten. Mit der reinen WinApi (oder aber auch mit der MFC) bleibst du auf Windows 3.1 Niveau oder musst sehr viel mehr Arbeit reinstecken, womit sich die Features dann überhaupt nicht mehr lohnen. Also bleibst du auf Windows 3.1 Niveau
Ich mag die MFC auch überhaupt nicht, aber bevor man völlig sinnlos ewig viel Zeit reinsteckt, um nur paar simple Fenster und Buttons hinzubekommen, dann doch lieber das.

Swordfish

...

Beefi

Ähm ... Qt benutzt immer wo möglich die nativen Steuerelemente der Plattform ...

Sicher? Meines Wissens zeichnet Qt seine Steuerelemente selbst. Zeichnet jedoch perfekt die nativen Steuerelemente nach. Aber vielleicht hat sich da ja was geändert.
Von den großen Cross-Plattform-Frameworks, welches unter Windows tatsächlich nativ auf die WinAPI greift, ist mir jetzt nur wxWidgets bekannt.
wxWidgets ist quasi eine Ummantelung der WinAPI, wie etwa die MFC. Qt macht sein ganz eigenes Ding.

Mit wxWidgets wäre mein Problem ja eigentlich gelöst. Wie gesagt hab ich jedoch schon oft gelesen, dass es ein zusammengeschustertes Framework ist, welches eine schlechte Doku hat und auch noch langsam läuft. Wenn ich schon C++ verwende, möchte ich nicht unbedingt ein langsames Framework, welches mir das Programm ausbremst. Oder sind das alles nur Gerüchte?
Bei wxWidgets wäre ich aber garantiert auf der sicheren Seite, dass es das Projekt noch lange gibt. Viele Frameworks für Windows brachen ihre Entwicklung ja einfach plötzlich ab

@Mechanics:
Nee, das ist wirklich nur reines Hobby. Ich werde C++ beruflich auch weiterhin nur für Nicht-GUI Dinge benötigen Frameworks wie Qt sind vielleicht für pure Softwarefirmen interessant, aber das ist ja nicht mein Arbeitsgebiet

Swordfish

...

Belli

Ich weiß nicht, was Du unter 'in eine PictureBox zeichnen' verstehst ... aber vom Prinzip her geht es bei der ganzen GUI-Programmierung doch immer darum, in ein Fenster zu zeichnen.
Wenn ich mich recht erinnere, geht es gleich in einem der ersten Tutorials zu Win32++ darum, mit der Maus in einem Fenster rumzuzeichnen.
Dass man das dann auch irgendwie drucken kann, steht außer Frage, WIE das allerdings zu bewerkstelligen ist, weiß ich nicht, weil ich mich mit dem Thema noch nie befasst habe. Deshalb weiß ich auch nicht, ob Win32++ da was fertiges anbietet.
Ebensowenig kann ich Dir sagen, ob es weiterentwickelt wird ... wenn Du immer und ständig die neuesten GUI-Features brauchst, ist ein professionelles Werkzeug von Microsoft oder Borland wahrscheinlich besser geeignet.
Einen Dialog zur Auswahl von Dateien zum Speichern/Laden bietet die WinAPI schon fertig an, den kannst Du auch einfach aus einem Konsolenprogramm aufrufen.
Ebenso wie einige andere je nach Bedarf nützliche Dialoge:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff468806(v=vs.85).aspx

Die Oberfläche für die GUI kann man schön mit einem Ressourceneditor erstellen (ich nehme ResEdit dafür, es gibt sicher noch andere), die Programmierung dann mit Win32++.
Wenn ein wenig Grundlagenwissen über Win-Programme (Fenster, Messages, Message-Handling) vorhanden ist, kann man sich recht schnell in Win32++ einarbeiten.

Bei Frameworks wie der MFC oder Borland ist nach meiner Einschätzung weniger Grundlagenwissen erforderlich - man kommt wohl (zumindest zu Beginn) schneller ans Ziel, weil man einige Zusammenhänge gar nicht begreifen muss.

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.