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

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

  • B

    Wofür genau musst du C++ denn beruflich einsetzen?

    Ich komm aus der Elektronik-Branche...und heutzutage steckt ja fast überall ein Minicomputer drin. Vor ca 10 Jahren war noch C und Assembler angesagt, womit wir Microcontroller programmierten (zb. PIC oder Atmel AVR)...jetzt müssen wir C++ beherrschen, weil fast überall ein kleines Linux drinsteckt.
    Also kurz gesagt benötige ich C++ für Embedded-Systeme.
    Privat für normale PC-Programmierung (Windows) war ich eigentlich immer der VB6-Typ bzw. jetzt lerne ich mich so langsam in .NET ein 🙂

    Sowas kannst du auf jeden Fall auch mit der WinAPI machen und wär vermutlich auch keine schlechte Übung.

    Ok, dazu noch eine Frage. In Visual Studio kann ich Fenster einfach zeichnen und dann in den entsprechenden Funktionen/Ereignissen meinen Code platzieren.
    Programmiere ich nur über die WinAPI, kann ich das ja mithilfe eines Resourcen-Editors machen. Wenn ich hiermit die Steuerelemente gezeichnet habe, muss ich diese dann nur noch per eingebundener API-Funktion ansprechen? Bzw ist es nur ein kleiner Mehraufwand im Vergleich zu VB6? Oder stelle ich mir das viel zu einfach vor? 🙂

    0
  • ?

    Ach volkard, wieso löschst du immer meine Posts -.-

    0
  • B

    Was stand denn im Post? 🙂

    0
  • -

    Beefi schrieb:

    Vor ca 10 Jahren war noch C und Assembler angesagt, womit wir Microcontroller programmierten (zb. PIC oder Atmel AVR)...jetzt müssen wir C++ beherrschen, weil fast überall ein kleines Linux drinsteckt.

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

    0
  • B

    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.

    0
  • K

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

    0
  • B

    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.

    0
  • M

    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.

    0
  • B

    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?

    0
  • M

    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.

    0

  • ...

    0
  • B

    Ä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 🙂

    0

  • ...

    0
  • B

    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.

    0
  • B

    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!

    0
  • B

    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 🙂

    0
  • B

    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?

    0
  • M

    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?

    0
  • B

    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.

    0
  • M

    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.

    0
Anmelden zum Antworten