it-swarm.dev

Warum werden nicht mehr Desktop-Apps mit Qt geschrieben?

Soweit ich weiß und in meiner Erfahrung mit Qt verstanden habe, ist es eine sehr gute und leicht zu erlernende Bibliothek. Es hat eine sehr gut gestaltete API und ist plattformübergreifend. Dies sind nur zwei der vielen Funktionen, die es attraktiv machen. Ich bin interessiert zu wissen, warum mehr Programmierer Qt nicht verwenden. Gibt es einen Mangel, der dagegen spricht? Welche Funktion macht andere Bibliotheken besser als Qt? Bezieht sich das Problem auf die Lizenzierung?

205
Dehumanizer

Ich beabsichtige nicht wirklich, dass dies eine verprügelnde Antwort ist, aber dies sind die Gründe, warum ich Qt nicht persönlich benutze. Es gibt viele gute Dinge zu sagen - nämlich, dass die API die meiste Zeit funktioniert und Plattformen nahtlos überbrückt. Aber ich benutze Qt nicht, weil:

  1. In einigen Fällen sieht es einfach nicht so aus, als würden native Programme aussehen. Das Entwerfen einer einzelnen Benutzeroberfläche für alle Plattformen wird aus verschiedenen Gründen des visuellen Stils von Maschine zu Maschine nicht richtig aussehen. Auf Mac-Computern sind beispielsweise geteilte Balken normalerweise relativ dick, und die Schaltflächen sind klein und mit Symbolen abgerundet. Auf Windows-Computern sind geteilte Balken normalerweise schmal und Schaltflächen sind textueller und quadratischer gestaltet. Nur weil Sie für jede Plattform eine Benutzeroberfläche schreiben können, bedeutet dies nicht, dass Sie dies für die meisten Anwendungen tun sollten.
  2. Qt ist keine C++ - Bibliothek. Es erfordert einen separaten Kompilierungsschritt, was den Erstellungsprozess im Vergleich zu den meisten anderen Bibliotheken viel komplizierter macht.
  3. Aufgrund von (2) können C++ - IDEs und -Tools Qt-Ausdrücke als Fehler kennzeichnen, da sie die Besonderheiten von Qt nicht verstehen. Dies erzwingt fast die Verwendung von QtCreator oder eines Nur-Text-Editors wie vim.
  4. Qt ist eine große Menge an Quelle, die auf jedem Computer vorhanden und vorinstalliert sein muss, den Sie vor dem Kompilieren verwenden. Dies kann das Einrichten einer Build-Umgebung viel mühsamer machen.
  5. Es ist nur unter LGPL verfügbar, was es schwierig macht, die Single-Binary-Bereitstellung zu verwenden, wenn eine Veröffentlichung unter einer restriktiveren oder weniger restriktiven Lizenz erforderlich ist.
  6. Es erzeugt extrem große kompilierte Binärdateien im Vergleich zu ähnlich geschriebenen "einfachen alten nativen Anwendungen" (mit Ausnahme von natürlich für KDE geschriebenen Anwendungen).
178
Billy ONeal

Wie die Leute sagen, passt jedes Werkzeug zu jedem Problem und jeder Situation ...

Aber wenn Sie C++ - Programmierer sind, ist Qt Ihr Framework. Kein Rivale.

Wir entwickeln eine komplexe kommerzielle Anwendung für die medizinische Bildgebung, und Qt hält daran fest.

Ich sage nicht, dass die 'Nachteile', die die Leute darüber sagen, falsch sind, aber ich habe das Gefühl, dass sie Qt schon lange nicht mehr ausprobiert haben (es verbessert sich kontinuierlich bei jeder neuen Version ...). Und meistens Alle von ihnen kommentierten Probleme sind kein Problem, wenn Sie vorsichtig sind.

Inkonsistenz der UI-Plattform: Nur wenn Sie die UI-Widgets so verwenden, wie sie sind, ohne Anpassung oder benutzerdefinierte Grafik.

Qt-Präprozessorüberlastung: Nur wenn Sie den Signal-Slot-Mechanismus oder die QObject-Vererbung missbrauchen, wenn dies nicht wirklich erforderlich ist.

Übrigens schreiben wir immer noch Anwendungen in C # .NET und das schon lange. Ich glaube, ich habe eine gute Perspektive.

Wie gesagt, jedes Werkzeug für jede Situation,

aber Qt ist ohne Zweifel ein konsistenter und nützlicher Rahmen.

116
Inigo

Von all den Dingen, die ich an Qt nicht mag, nervt mich die Tatsache, dass es mit Vorlagen nicht gut funktioniert, am meisten. Das kannst du nicht machen:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

Es spielt auch nicht gut mit dem Präprozessor. Das kannst du nicht machen:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

Dies, gemischt mit der Tatsache, dass alles, was auf ein Signal reagiert, ein Q_OBJECT sein muss, macht es für einen C++ - Programmierer schwierig, Qt zu bearbeiten. Die Leute pflegten Java oder Python Style-Programmierung wahrscheinlich tatsächlich besser).

Ich habe tatsächlich viel Zeit und Mühe darauf verwendet, einen Weg zu finden und zu finden, um die Typensicherheit wiederherzustellen und ein Qt-Signal mit einem beliebigen Funktorobjekt zu verbinden: http://crazyeddiecpp.blogspot.com/2011/01/quest-for -sane-Signale-in-qt-Schritt-1.html

Die Art von Dingen, die ich dort machen möchte, ist eine grundlegende, alltägliche C++ - Entwicklung, die vom Qt-Moc so gut wie unmöglich gemacht wird ... was selbst heutzutage völlig unnötig ist, wenn es jemals tatsächlich war.

Ehrlich gesagt, ich bleibe dabei, denn wenn Sie automatisierte UI-Tests durchführen möchten, ist Qt so ziemlich das einzige Spiel in der Stadt, das nicht MFC ist ... das ist so 1980 (es ist scheiße, in dieser Scheiße wirklich hart zu arbeiten). Einige mögen WX sagen, aber es gibt noch ernstere Probleme. GTKmm wäre meine erste Wahl gewesen, aber da alles vom Eigentümer gezeichnet wurde und keine Zugänglichkeit bietet, kann es nicht von branchenüblicher Testsoftware gesteuert werden. Qt ist in dieser Hinsicht schwer genug ( funktioniert kaum , wenn Sie das Eingabehilfen-Plugin ändern).

37
Edward Strange

Ein Grund, Qt nicht zu verwenden, ist, dass Sie, wenn Sie nur für eine Architektur wie Windows schreiben, möglicherweise C # /. NET (oder Cocoa auf Mac) verwenden möchten, da diese ausnahmslos die neuesten Funktionen nutzen können -Pfeifen des Betriebssystems.

Wenn Sie plattformübergreifende Apps schreiben, sind Sie möglicherweise bereits stark an einer anderen Technologie interessiert, z. B. Java (dh Sie arbeiten in einem "Java-Shop"). Ihre Wahl der Technologie kann diktiert sein Durch das Ökosystem, in dem Sie entwickeln, z. B. sprachspezifische APIs. In solchen Fällen kann es von Vorteil sein, die Anzahl der Technologien zu minimieren.

Ein dritter Grund, an den ich denken kann, ist, dass Qt auf C++ basiert und C++ eine vergleichsweise schwierig/gefährliche Sprache zum Programmieren ist. Ich denke, es ist eine Sprache für Profis. Wenn Sie Spitzenleistung benötigen und akribisch sein können, ist C++ wahrscheinlich immer noch das beste Spiel der Stadt. Tatsächlich verbessert Qt viele Probleme bei der Speicherverwaltung, wenn Sie Dinge so einrichten, dass sie nicht mehr in den Geltungsbereich fallen. Außerdem leistet Qt selbst gute Arbeit, um den Benutzer vor vielen unangenehmen C++ - Problemen zu schützen. Jede Sprache und jedes Framework hat ihre Vor- und Nachteile. Es ist ein sehr, sehr kompliziertes Problem, das normalerweise durch den Zusatz zusammengefasst werden kann, der häufig bei Gästen auftritt: Geschwindigkeit, Qualität und Preis (Sie können jedoch nur zwei auswählen).

Obwohl die Regeln besagen, dass ich mich weiterhin auf die Beantwortung der Frage konzentrieren sollte, möchte ich einige der von Billy ONeal aufgeworfenen Fragen widerlegen, der meiner Meinung nach gute Arbeit leistet und die häufig genannten Gründe für die Nichtverwendung von Qt zusammenfasst:

  1. Qt ist in der Tat eine C++ - Bibliothek/Framework/Header-Dateien. Es wird erweitert von einem Makroprozessor (moc) verwendet, der unter anderem Signale und Slots ermöglicht. Es transformiert zusätzliche Makrobefehle (wie z. B. Q_OBJECT), sodass Klassen Introspektion und alle möglichen anderen Extras haben, die Sie als Hinzufügen von Objective-C-Funktionen zu C++ betrachten könnten. Wenn Sie genug über C++ wissen, um von diesem Mangel an Reinheit beleidigt zu werden, dh Sie sind ein Profi, dann 1) verwenden Sie nicht Q_OBJECT und seine Art oder 2) seien Sie dankbar, dass es dies tut, und programmieren Sie um die sehr begrenzten Eckfälle wo dies ein Problem verursacht. Für Leute, die sagen "Verwenden Sie Boost für Signale und Slots!" dann würde ich erwidern, dass Sie ein "Problem" gegen ein anderes austauschen. Boost ist riesig und hat seine eigenen häufig zitierten Probleme wie schlechte Dokumentation, schreckliche API und plattformübergreifende Horror (denken Sie an alte Compiler wie gcc 3.3 und große Eisen-Compiler wie AIX).

  2. Für die Editorunterstützung folgt dies auch aus 1, da stimme ich etwas zu. Tatsächlich ist Qt Creator meiner Meinung nach der beste grafische C++ - Editor, Punkt, auch wenn Sie das Qt-Zeug nicht verwenden. Viele professionelle Programmierer verwenden Emacs und Vim. Ich denke auch, dass Eclipse die zusätzliche Syntax übernimmt. Somit gibt es keine Probleme mit den Qt-Makros (Q_OBJECT) oder den Hinzufügungen von Signalen/Slots. Sie werden diese Makros wahrscheinlich nicht in Visual Studio finden, da sie (ich gebe zu) Ergänzungen zu C++ sind. Aber im Großen und Ganzen werden C # /. NET-Leute Qt sowieso nicht verwenden, da sie einen Großteil der Funktionen haben, die mit ihren eigenen proprietären Techniken abgedeckt werden.

  3. Wen interessiert die Größe der Qt-Quelle, solange sie über Nacht kompiliert wird? Ich habe Qt 4 auf meinem Dual-Core-Macbook in "weniger als über Nacht" kompiliert. Ich hoffe auf jeden Fall, dass dies nicht der Grund für Ihre Entscheidung ist, eine bestimmte Technologie zu verwenden oder nicht zu verwenden. Wenn dies wirklich ein Problem ist, können Sie die vorkompilierten SDKs für Mac, Linux und Windows von der Qt-Website herunterladen.

  4. Die Lizenzierung ist in drei Optionen verfügbar: 1) Proprietäre Lizenz für den Fall, dass Sie Qt SELBST ändern und nicht teilen oder die Tatsache verbergen möchten, dass Qt und verwendet werden keine Namensnennung (könnte für Branding und Image sehr wichtig sein!) 2) GPL und 3) LGPL. Ja, es gibt Probleme mit der statischen Verknüpfung (das gesamte Qt wird in die Binärdatei gerollt) - aber ich denke, das ist mehr, weil man nicht hineinschauen und feststellen kann, dass Sie Qt verwenden (Attribution!). Ich habe versucht, eine proprietäre Lizenz von Digia zu kaufen, und sie sagten mir: "Für das, was Sie tun, brauchen Sie es wirklich nicht." Beeindruckend. Von einem Unternehmen, das Lizenzen verkauft.

  5. Die Größe der Binärdatei/des Bundles ist darauf zurückzuführen, dass Sie das Qt-Material an Leute verteilen müssen, die es nicht haben: Windows hat es bereits? das Visual Studio-Zeug oder Sie müssen die Laufzeit installieren. Mac kommt bereits mit dem riesigen Kakao und kann dynamisch verknüpft werden. Obwohl ich nicht viel verteile, habe ich nie große Probleme beim Verteilen der statischen Datei mit ~ 50 Megabyte festgestellt (die ich mit einigen der Dienstprogramme für binäre Stripper/Komprimierung wie UPX noch verkleinern kann). Es ist mir einfach nicht wichtig genug, dies zu tun, aber wenn Bandbreite jemals ein Problem wäre, würde ich meinem Build-Skript einen UPX-Schritt hinzufügen.

  6. Was macht "Native Look and Feel" aus? Ich denke, "die meisten" würden zustimmen, dass der Mac dem einheitlichen Erscheinungsbild am nächsten kommt. Aber hier sitze ich und schaue mir Safari, iTunes, Aperture, Final Cut Pro, Pages usw. an. Sie sehen sich nicht ähnlich, obwohl sie vom Betriebssystemhersteller hergestellt wurden. Ich denke, der Aspekt "Gefühl" ist relevanter: Widget-Stil, Reaktionsfähigkeit usw. Wenn Sie sich für Reaktionsfähigkeit interessieren, ist hier ein guter Grund, C++ anstelle von Java oder einer anderen hochdynamischen Sprache zu verwenden. (Ziel C rockt auch, aber ich versuche Mythen über Qt zu zerstreuen)

Zusammenfassend ist es ein kompliziertes Problem. Ich möchte jedoch darauf hinweisen, dass es meines Erachtens weniger Gründe gibt, "Qt nicht zu verwenden", als man aufgrund von Mythen und veralteten Informationen denken könnte.

28
Eric Brown

Ein Teil davon ist Lizenzierung. Unter https://en.wikipedia.org/wiki/Qt_ (Software) #Licensing finden Sie einen Teil des Lizenzverlaufs. Bis zum Jahr 2000 verwendeten Menschen, die sich stark für Open Source interessierten, Qt nicht. Zeitraum. (Dies war in der Tat die ursprüngliche Motivation für die Entwicklung von Gnome.) Bis 2005 verwendeten Personen, die freie Software für Windows veröffentlichen wollten, Qt nicht. Selbst nach diesem Datum hatten Leute, die freie Software unter etwas anderem als der GPL wollten, einfach nicht die Möglichkeit, Qt zu verwenden. Daher konnte kein freies Softwareprojekt, das älter als diese Daten ist, Qt nicht verwenden. Und natürlich mussten Leute, die proprietären Code schreiben, für das Privileg bezahlen.

Darüber hinaus ist es nicht so, als ob es an anderen Optionen mangelt. Zum Beispiel sind WxWidgets , GTK + und Tk alle plattformübergreifende Open Source-Toolkits.

Darüber hinaus war Windows lange Zeit auf dem Desktop so dominant, dass viele Software-Inhalte nur unter Windows ausgeführt werden konnten. Wenn Sie die Microsoft-Toolchain installieren, ist es einfacher, nur Microsoft-proprietäre Inhalte zu verwenden, als sich um irgendetwas anderes zu kümmern, und viele Programmierer haben genau das getan.

26
btilly

Ich stimme fast allen oben diskutierten Gründen zu, aber viele Leute hier haben gesagt, dass sie Qt wegen des zusätzlichen Overheads, den es mit sich bringt, nicht verwenden würden. Ich bin damit nicht einverstanden, da alle gängigen Sprachen (Java, C # und Python) selbst einiges an Aufwand verursachen.

Zweitens macht Qt das Programmieren mit C++ so einfach und unkompliziert, dass es die zusätzlichen Ressourcen ausgleicht, die es verwendet. Ich bin auf einige Konsolenanwendungen gestoßen, die in Qt und nicht in Standard-C++ geschrieben wurden, weil sie einfach geschrieben werden können.

Ich würde sagen, dass die Produktivität von Qt höher ist als die von C/C++, aber geringer als die von Sprachen wie Python.

14
W.K.S

Dies ist wirklich kein Versuch, einen Flammenkrieg zu beginnen, ich wollte nur einige der Punkte ansprechen.

Wahrscheinlich ist der wahre Grund dafür, dass Qt nicht häufiger verwendet wird, dass es C++ ist und weniger Menschen C++ für Desktop-Apps verwenden.

Qt ist keine C++ - Bibliothek. Es erfordert einen separaten Kompilierungsschritt, was den Erstellungsprozess im Vergleich zu den meisten anderen Bibliotheken viel komplizierter macht.

Das vs-Add-In für Visual Studio erledigt dies automatisch, ebenso wie Qts eigener Befehlszeilen-Erstellungsprozess. Der Ressourcen-Compiler, der zum Erstellen der Dialoge für MFC verwendet wird, ist ebenfalls ein separater Schritt, aber das ist immer noch C++.

Qt ist eine große Menge an Quelle, die auf jedem Computer vorhanden und vorinstalliert sein muss, den Sie vor dem Kompilieren verwenden. Dies kann das Einrichten einer Build-Umgebung viel mühsamer machen.

Für jede Version von Visual Studio gibt es einen binären Download, und der Build aus dem Quellcode ist ein einzelner Befehl. Ich sehe nicht, dass die Größe der SDK-Quelle heutzutage so wichtig ist. Visual Studio installiert jetzt alle C++ - Bibliotheken, anstatt dass Sie auswählen können. Daher beträgt die Installationsgröße des Compilers> 1 GB.

Es ist nur unter LGPL verfügbar, was es schwierig macht, die Single-Binary-Bereitstellung zu verwenden, wenn eine Veröffentlichung unter einer restriktiveren oder weniger restriktiven Lizenz erforderlich ist.

Die LGPL gilt nur für die Bibliothek, sie hat keinen Einfluss auf Ihren Code. Ja, es bedeutet, dass Sie DLLs anstatt einer einzelnen Binärdatei versenden müssen (es sei denn, Sie zahlen), aber in einer Welt, in der Sie eine Java Laufzeit oder ein .Net-Update für einen winzigen Util herunterladen müssen) ist keine so große Sache. Es ist auch weniger ein Problem auf Plattformen mit einem einzigen ABI, so dass andere Qt-Apps die Bibliotheken teilen können.

In einigen Fällen sieht es einfach nicht so aus, als würden native Programme aussehen. Das Entwerfen einer einzigen Benutzeroberfläche für alle Plattformen wird aus verschiedenen Gründen des visuellen Stils von Maschine zu Maschine nicht richtig aussehen.

Es soll native Widgets und Themen verwenden. Ich muss zugeben, dass ich hauptsächlich technische Apps mache, damit meine Benutzer sich nicht zu sehr um den Stil kümmern. Besonders unter Windows bedeutet die neue Mode, alles als Smartphone-Widget zu gestalten, dass es sowieso immer weniger Standards gibt.

11
Martin Beckett

Der Grund ist einfach: Es hat keine guten Bindungen zu allen gängigen Sprachen und es ist nicht magisch immer für den jeweiligen Job geeignet.

Verwenden Sie das richtige Werkzeug für den Job. Wenn ich eine einfache Befehlszeilenanwendung schreibe, warum sollte ich das nur deswegen mit Qt aufblähen?

Als allgemeinere Antwort (die ich geben kann, weil ich hier relevant bin) haben einige Programmierer es einfach nie ausprobiert und beschlossen, es zu verwenden. In einigen Fällen gibt es keinen besonderen Grund, außer dass der Programmierer nie einen Bedarf dafür gefunden und sich damit befasst hat.

Frameworks wie Qt sind geeignet, wenn Sie sich mehr mit dem Aussehen Ihres Produkts befassen dasselbe auf allen Plattformen als mit dem Aussehen Ihres Produkts rechts auf allen Plattformen. Heutzutage werden solche Anwendungen immer häufiger auf webbasierte Technologien umgestellt.

5
Caleb

Ich bin damit einverstanden, dass Qt ein schönes Framework ist, mit dem man arbeiten kann. Dennoch gibt es eine Reihe von Problemen, die ich damit habe:

  1. Es ist in C++ geschrieben, einer sehr einfachen Sprache. Allein die Tatsache, dass es sich um C++ handelt, macht jeden Qt-Programmierer im Vergleich zu in anderen Sprachen geschriebenen Frameworks deutlich weniger produktiv. Mein Hauptproblem bei C++ als GUI-Entwicklungssprache ist, dass es so gut wie keine Vorstellung von automatischer Speicherverwaltung gibt, was den Entwicklungsprozess viel fehleranfälliger macht. Es ist nicht introspektiv, was das Debuggen viel schwieriger macht. Die meisten anderen wichtigen GUI-Toolkits haben eine Vorstellung von automatischer Speicherverwaltung und Selbstbeobachtung.
  2. Jedes plattformübergreifende Toolkit hat das Problem, dass es immer nur den kleinsten gemeinsamen Nenner aller unterstützten Plattformen implementieren kann. Dies und unterschiedliche UI-Richtlinien auf verschiedenen Plattformen stellen die Wünschbarkeit plattformübergreifender GUIs insgesamt sehr in Frage.
  3. Qt konzentriert sich sehr darauf, Ihre gesamte Benutzeroberfläche zu codieren. Obwohl Sie QtDesigner verwenden können, um einige Teile Ihrer Benutzeroberfläche zu erstellen, fehlt es im Vergleich zur (Cocoa/Obj-C) -Schnittstelle ernsthaft Builder oder die .Net-Tools.
  4. Obwohl Qt viele Anwendungsfunktionen auf niedriger Ebene enthält, kann es nicht mit einem Framework verglichen werden, das auf eine bestimmte Plattform von Hand zugeschnitten ist. Die nativen Betriebssystembibliotheken für Windows und OSX sind erheblich leistungsfähiger als die Implementierungen von Qt. (Denken Sie an Audio-Frameworks, einfachen Dateisystemzugriff usw.)

Trotzdem liebe ich es, PyQt für Rapid Application Prototyping oder Inhouse-Anwendungen zu verwenden. Die Verwendung von Python für die gesamte Codierung) lindert die Probleme mit C++ und macht Qt tatsächlich zu einem sehr angenehmen Ort.


Bearbeiten, als Antwort auf einige Kommentare :

Als ich darüber schrieb, dass Qt in C++ geschrieben wurde, beschwerte ich mich nicht so sehr über Qt selbst, sondern mehr über die Umgebung, in der es lebt. Es ist wahr, dass Qt seine eigenen Ressourcen sehr gut verwaltet, aber all Ihre GUI-bezogenen, aber Nicht-Qt-Code muss auch in C++ geschrieben werden. Selbst dort bietet Qt viele nette Tools, aber letztendlich müssen Sie sich auf dieser Ebene mit C++ befassen. Qt macht C++ erträglich, aber es ist immer noch C++.

Was Introspektion betrifft, meine ich Folgendes: Die am schwierigsten zu debuggenden Fälle sind, wenn Sie einen Zeiger auf ein Objekt haben, das sich nicht so verhält, wie Sie es sich vorstellen. Mit C++ kann Ihr Debugger möglicherweise ein wenig in dieses Objekt hineinschauen (wenn es zu diesem Zeitpunkt Typinformationen gibt), aber selbst das funktioniert nicht immer. Nehmen Sie andererseits Kakao in der gleichen Situation. In Cocoa/Obj-C können Sie Nachrichten ('Aufruffunktionen') direkt im Debugger an ein Objekt senden. Sie können den Objektstatus ändern, Sie können ihn nach seinen Attributen abfragen, Sie können ihn nach seinem Typ und seinen Funktionsnamen fragen ... Dies kann das Debuggen wesentlich komfortabler machen. Qt/C++ hat nichts in der Nähe.

4
bastibe

meiner Meinung nach ist das Erlernen der C++ - Programmierung einfacher, als in andere Sprachen zu fallen, die ihre Komplexität verbergen, und der Programmierer weiß nicht, was wirklich im Hintergrund passiert. Qt hingegen bietet einige Vorteile gegenüber C++, um es höher als natives C++ zu machen. Somit ist Qt C++ ein großartiges Framework für diejenigen, die Aufgaben auf niedriger oder hoher Ebene auf dieselbe Weise entwickeln möchten. C++ ist (nach einigen Methoden) eine komplexe und einfache Sprache. Komplex für diejenigen, die nicht damit herausfordern wollen, einfach für jemanden, der es mag. Lassen Sie es nicht für seine Komplexität!

4
user100691

Das Wichtigste, aber nicht Erwähnte. Bei großen Projekten verursacht eine Sache so viele Probleme und nicht notwendigen Code. Die Signalschlitzmechanismen von Qt sind ineffizient. Qt-Widgets liefern keine erforderlichen Signale für einfache Widgets für Ereignisse. Beispielsweise können Sie keine Signale für onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus usw. festlegen. Selbst das komplexeste Widget wie QTreeWidget bietet ein oder zwei extrem einfache nutzlose Signale.

Ja, Sie können Ereignisse verwenden, ABER !!! Sie haben für jedes Widget eine neue Klasse mit einem benutzerdefinierten Ereignis erstellt. Dies ist ein enormer Effizienzverlust.

  • Sie haben jedes angepasste Widget-Objektereignis neu geschrieben. Es gibt kleine Änderungen.
  • Sie verlieren alle Qt Designer-Sachen. Sie müssen jedes Widget mit benutzerdefinierten Ereignissen bewerben.
  • Das Projekt wurde größer und schwer zu warten.
  • Du hast aus diesem Grund angefangen, qt nicht zu mögen. Und wenn Sie anfangen darüber zu sprechen, wie .net Delegierte bereitstellt, wie es viel, viel besser ist als Signalschlitze, wie .net-Komponenten (Widgets) im Allgemeinen jedes Ereignis bereitstellen, das Sie sich vorstellen können. Und ETC.

Einer meiner Kollegen hat für jedes Kombinationsfeld-Widget eine neue Combo-Box-Klasse erstellt, da er ein Nicht-Signal-Ereignis verwenden musste. Wahre Geschichte...

Qt ist jedoch das bisher beste C++ - UI-Framework mit Höhen und Tiefen.

3
Obrix

Ich mag Qt wirklich, aber es ist ein bisschen schwer für viele Anwendungen. Manchmal braucht man diese Komplexität einfach nicht. Manchmal braucht man einfach etwas Einfaches ohne den ganzen Aufwand von Qt. Nicht jede Anwendung muss ereignisgesteuert sein, und C++ bietet einen angemessenen Satz von Vorlagen. Boost bietet einen weiteren sehr guten Satz und enthält viele der Funktionen auf niedriger Ebene (Datei, Socket, verwaltete Zeiger usw.), die QT bietet.

Andere Anwendungen haben Lizenzanforderungen, die mit GPL, LGPL oder der kommerziellen Lizenz von Qt nicht gut funktionieren. Die GPL ist für kommerzielle Software ungeeignet. Die LGPL ist für statisch verknüpfte Software ungeeignet und die kommerzielle Lizenz kostet Geld - etwas, das viele nicht bezahlen wollen.

Einige haben Sicherheits- oder Stabilitätsüberlegungen, die komplexe Bibliotheken wie Qt nicht zulassen.

Sie müssen moc ausführen, um Ihre Quellen vorzuverarbeiten. Das ist kein großes Problem, aber es kann für den neuen Benutzer entmutigend sein. Viele Programmierer denken, dass Sie brauchen, um qmake mit Qt zu verwenden, aber das ist eine falsche Bezeichnung. Es ist ziemlich einfach, Qt in andere Build-Systeme einzubinden.

Einige Ziele sind sehr speicher- oder CPU-eingeschränkt.

Es gibt einige plattformspezifische Fallstricke. Die meisten dieser Fallstricke sind nicht dokumentiert. Wenn Sie eine ausreichend große Anwendung erstellen, werden Sie auf sie stoßen und sich fragen, was los ist (Haftungsausschluss, das letzte Mal, dass ich Qt im Zorn verwendet habe, war vor über 18 Monaten, daher hat es sich möglicherweise verbessert).

Es ist nur C++. Es gibt andere Sprachbindungen, die jedoch dazu neigen, viele der Funktionen, für die Sie Qt benötigen, zu verbergen oder schlecht verfügbar zu machen.

Es gibt viele Gründe, Qt nicht zu verwenden, deshalb gibt es Alternativen. Wenn Sie nur einen Hammer haben, sieht jedes Problem wie ein Nagel aus.

3
Adam Hawes

Der eigentliche Grund ist nicht technisch.

Die Leute sind zufällig anders. So sind ihre Entscheidungen. Einheitlichkeit ist kein menschliches Merkmal.

2
mouviciel