Warum werden nicht mehr Desktop-Apps mit Qt geschrieben? [geschlossen]

202

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 gespannt, warum mehr Programmierer Qt nicht verwenden. Gibt es einen Mangel, der dagegen spricht? Welche Eigenschaft macht andere Bibliotheken besser als Qt? Hat das Problem mit der Lizenzierung zu tun?

Dehumanizer
quelle
60
Es ist natives C ++. Die meisten Entwickler würden höhere Sprachen wie C # bevorzugen.
user16764
15
Das zweischneidige Schwert der Rückwärtskompatibilität hat Qt mit vielen Anachronismen, unfixierbaren Fehlern und anderem schlechten Verhalten zurückgelassen.
edA-qa mort-ora-y
26
@ user16764: "Most"?
Leichtigkeitsrennen im Orbit
17
Ich denke nicht, dass der TIOBE-Index ein wirklich genaues Maß ist, weil er die Popularität misst, nicht die Verwendung. Ein Vergleich der Codemenge in Open Source-Repositorys wie GitHub, Bitbucket, Codeplex und Sourceforge würde genauere Messungen ergeben. (Und ich glaube, dass diese genaueren Messungen C und C ++ an die ersten und zweiten Stellen bringen - Java hat einen unfairen Vorteil im TIOBE-Index, da es für Studienanfängerkurse verwendet wird und neue Programmierer mehr Aufsehen erregen als erfahrene)
Billy ONeal
12
@ Giorgio: Ähm, du musst über solche Dinge in C # nachdenken. Der Begriff "Wem gehört das" geht weit über "Wer ruft delete" hinaus. Die Tatsache, dass die intelligenten Zeiger dies explizit machen, ist kein Sprachfehler. und wenn Sie nicht über solche Dinge nachdenken, werden Sie Müll in jeder höheren Sprache erzeugen, die ich auch gesehen habe.
Billy ONeal

Antworten:

177

Ich habe nicht wirklich vor, dass dies eine heftige Antwort ist, aber das sind die Gründe, warum ich Qt nicht persönlich benutze. Es gibt viele gute Dinge darüber 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, wie native Programme aussehen. Das Entwerfen einer einzigen Benutzeroberfläche für alle Plattformen wird aus verschiedenen Gründen des visuellen Stils nicht richtig aussehen, wenn sie von Maschine zu Maschine verschoben wird. Beispielsweise sind auf Mac-Computern geteilte Balken normalerweise relativ dick und Schaltflächen sind klein und mit Symbolen abgerundet. Auf Windows-Computern sind geteilte Balken in der Regel schmal und Schaltflächen sind textueller und haben mehr quadratische Designs. Nur weil Sie eine Benutzeroberfläche für jede Plattform schreiben können, sollten Sie dies für die meisten Anwendungen nicht tun.
  2. Qt ist keine C ++ - Bibliothek. Es ist ein separater Kompilierungsschritt erforderlich, wodurch der Erstellungsprozess im Vergleich zu den meisten anderen Bibliotheken viel komplizierter wird.
  3. Infolge 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 reinen Texteditors vim.
  4. Qt ist eine große Menge an Quellcode, die auf jedem Computer vorhanden und vorinstalliert sein muss, den Sie verwenden, bevor Sie kompilieren. Dies kann das Einrichten einer Build-Umgebung erheblich erschweren.
  5. Es ist nur unter LGPL verfügbar, was es schwierig macht, Single-Binary-Deployment zu verwenden, wenn eine Freigabe unter einer restriktiveren oder weniger restriktiven Lizenz erforderlich ist.
  6. Es erzeugt extrem große kompilierte Binärdateien im Vergleich zu ähnlich geschriebenen "normalen" nativen Anwendungen (mit Ausnahme von natürlich für KDE geschriebenen Anwendungen).
Billy ONeal
quelle
11
@ Dehumanizer: Es gibt die LGPL-Lizenz und es gibt die kommerzielle Lizenz. Die kommerzielle Lizenz kostet seitens des Lizenznehmers Tausende von Dollar und erlaubt keine Weiterverteilung usw. Für Open-Source-Projekte unter liberalen Lizenzen wie BSD, MIT oder Boost, bei denen die Autoren nicht viel Geld verdienen und es sich wünschen Um ihren Code unter einer liberalen Lizenz freizugeben, ist eine Abhängigkeit von der LGPL nicht zumutbar, aber die betreffenden Entwickler können sich eine kommerzielle Lizenzierung im Allgemeinen nicht leisten.
Billy ONeal
27
# 6 ist der größte Grund, warum ich es vermeide. Ich meine, ich möchte kein großes, klobiges Programm, und ich bin nicht gerne an eine bestimmte Lizenz gebunden, aber es ist wirklich das Fehlen eines guten, einheimischen Look-and-Feel, das für mich einen Deal-Breaker darstellt. Die neuesten Versionen von OSX und Windows haben ihre nativen Benutzeroberflächen auf fantastische Weise hübsch, schnell und funktionell gestaltet, und ich würde lieber die gesamte Arbeit nutzen, die sie bereits für mich geleistet haben. Ich finde, dass sich viele Programme ohne nativen Look für mich billig und hackig anfühlen (nicht immer, aber es macht mich ein bisschen fertig).
Greg Jackson
16
Ihre Nummer 6 hätte Nummer 1 sein sollen. Dies ist mit Abstand das größte Problem mit Qt. In vielen Fällen werden die nativen APIs einfach nicht verwendet. Ich mag meine Software, um gebürtig zu schauen. Benutzern gefällt das auch. Ich habe noch nie eine Mac-Anwendung gesehen, die mit Qt erstellt wurde und wie eine Mac-Anwendung aussah. Weder haben Sie noch andere Mac-Benutzer, und sie sind über solche Dinge wählerisch. Sie verlieren den Vorteil, dass es "plattformübergreifend" ist, wenn Sie es nur zum Erstellen von Linux-Anwendungen verwenden. Dies ist ungefähr der einzige Ort, an dem es nativ aussieht, weil es wirklich nichts natives gibt.
Cody Grey
41
außer das problem des 'native' look gibt es nicht mehr. Die alte Konsistenz von Windows-Apps ist jetzt eine Bastardisierung der einzigartigen Blobs, Glows und Animationen, die Sie mit WPF und Silverlight erhalten. Schauen Sie sich die Systemsteuerung von Office oder Windows 7 an, um zu sehen, wie inkonsistent die Benutzeroberfläche von MSs Flaggschiffprodukten heutzutage ist. Mac-Benutzer - na ja, da haben Sie einen sehr gültigen Punkt.
gbjbaanb
5
@ TrevorBoydSmith: Sorry, aber du liegst falsch. Qt ist das einzige Framework, das die Vorverarbeitung verwendet. Zeitraum. Überprüfen Sie GNOME, FLTK, WX und Freunde und zeigen Sie mir einen Vorverarbeitungsschritt. Du wirst keinen finden. Einige andere Bibliotheken werden mit anderen Buildsystemen geliefert, aber letztendlich handelt es sich um C ++ - Bibliotheken, die von jedem C ++ - Compiler erstellt werden können. Was "Raw win32 in meinen Gründen nicht vorhanden" betrifft, so ist es in meinen Gründen als # 5 und # 6 vorhanden.
Billy ONeal
115

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

Wenn Sie jedoch C ++ - Programmierer sind, ist Qt Ihr Framework. Kein Rivale.

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

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 ständig mit jeder neuen Version ...). Und meistens Alle Probleme, die sie kommentieren, sind kein Problem, wenn Sie aufpassen.

Inkonsistenz der Benutzeroberflächenplattform: Nur wenn Sie die Benutzeroberflächen-Widgets unverändert verwenden, ohne Anpassungen oder benutzerdefinierte Grafiken.

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 zweifellos ein konsistenter und nützlicher Rahmen.

Inigo
quelle
9
+1 Danke! Ich wollte nur dasselbe schreiben. Der größte Unsinn ist "Nicht-Open-Source / kommerzielles Argument". Erstaunlich, wie falsch viele Menschen den Begriff Open-Source verstehen. Qt war Open Source, seit ich es benutze (1.4). Und es hatte früher die fairste Lizenz: Geld verdienen mit Qt -> bezahlen.
Valentin Heinitz
16
Oh, und ich mache mir wirklich keine Sorgen, wenn ich 10 MB DLLs zu einer Anwendung hinzufüge, die 50 MB Grafik und 200 MB Video-Tutorials und Daten enthält :)
Freitag,
9
Der Platzbedarf für Qt ist derzeit günstig.
Trusktr
5
Dies entspricht in etwa meiner Erfahrung mit Qt (dem Widgets-Framework, für das ich QML / QtQuick bisher noch nicht für ernsthafte Zwecke verwendet habe). Es eignet sich zum Schreiben großer Anwendungen mit komplexen UI-Anforderungen. Sobald Sie es gelernt haben, können Sie sehr produktiv sein. Die genannten Nachteile (separater Kompilierungsschritt für Mocing, UI-Dateien usw.) sind kein Problem, wenn das Build-System ordnungsgemäß eingerichtet ist. Ich kann entweder qmake oder cmake empfehlen.
Nils
Ab Qt 5.8 gibt es ein Projekt namens Qt Lite, das Qt extrem für Ihre spezifischen Anforderungen minimiert. Dies ist eine kommerzielle Funktion;)
SMMousavi
36

Von all den Dingen, die ich an Qt nicht mag, nervt mich die Tatsache, dass es nicht gut mit Vorlagen funktioniert. 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, zusammen mit der Tatsache, dass alles, was auf ein Signal reagiert, ein Q_OBJECT sein muss, macht es schwierig, in Qt für einen C ++ - Programmierer zu arbeiten. Die Leute, die an Java oder Python gewöhnt sind, sind wahrscheinlich tatsächlich besser.

Tatsächlich habe ich viel Zeit und Mühe aufgewendet, um einen Weg zu finden, um die Typensicherheit wiederherzustellen und ein Qt-Signal mit einem beliebigen Funktionsobjekt zu verbinden: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-qt-step-1.html

Was ich dort machen möchte, ist eine einfache, alltägliche C ++ - Entwicklung, die durch den Qt moc so gut wie unmöglich gemacht wurde ... was heutzutage selbst völlig unnötig ist, wenn es jemals tatsächlich so war.

Ehrlich gesagt bin ich dabei geblieben, denn wenn Sie automatisierte UI-Tests durchführen möchten, ist Qt so ziemlich das einzige Spiel in der Stadt, das nicht über MFC verfügt. Einige sagen vielleicht WX, aber es gibt noch ernstere Probleme. GTKmm wäre meine erste Wahl gewesen, aber da alles vom Eigentümer gezeichnet wurde und keine Barrierefreiheit bietet, kann es nicht mit einer branchenüblichen Testsoftware betrieben werden. Qt ist in dieser Hinsicht schwierig genug ( funktioniert kaum, wenn Sie das Accessibility-Plugin ändern).

Edward Strange
quelle
1
Was sind aus Interesse die Hauptprobleme bei WX?
Tom Anderson
7
@Tom - schlechte Dokumentation, besonders für die neuen Sachen. Die AUI-Komponenten sind mit fehlenden großen Abschnitten kaum dokumentiert, was den Einsatz in einer Produktionsumgebung erschwert. Die Dokumentation des Ereignisprozesses ist hinsichtlich des eingeschlagenen Pfades grundsätzlich fehlerhaft, zumindest auf win32. Verbrachte viel Zeit damit, den Computer anzuschreien: "Das sollte funktionieren !!!" Bevor Sie sich mit dem ausführlichen Verarbeitungscode befassen und herausfinden, dass WX den Dokumenten nicht folgt und was ich getan habe, NIEMALS funktioniert.
Edward Strange
1
Mich hat auch die Akzeptanz der Property Grid Library in der Hauptlinie gestört. Ich habe diese Bibliothek verwendet und sie hat neben dem tatsächlichen Mangel an Wissen im Auftrag des Programmierers, der sie geschrieben hat, zahlreiche grundlegende Designfehler gezeigt (beispielsweise als virtuelle Funktionen in Konstruktoren bezeichnet). Es und der arme Staat AUI zeigten einen Trend zu schlechteren Standards. Ich bin auch kein großer Fan von statischen Ereignistabellen, obwohl es zumindest eine andere Möglichkeit gibt, auf Ereignisse zu reagieren ... im Gegensatz zu MFC, dessen WX einfach zu aufregend ist, um überhaupt aufregend zu sein.
Edward Strange
Vielen Dank. Ich habe es nur ein bisschen benutzt und durch die wxPython-API, wo es ganz nett schien. Ich kann zu schätzen wissen, dass dies einige der Übel verbergen würde, aber auch, dass ich nicht tief genug involviert bin, um auf die ernsthafteren Probleme zu stoßen. Etwas, auf das ich achten muss.
Tom Anderson
1
Alles, was auf ein Signal reagiert, muss ein Q_OBJECT sein. Nein, heutzutage ... Jetzt können statische Funktionen, Funktionen und sogar Lambda-Funktionen auf ein Signal reagieren (Sie können Funktionszeiger als Slots verwenden). No-QObject-Klassen können auch über Member-Slots verfügen, wenn Sie mit std :: bind eine Verbindung herstellen, um das Instanz-Member in einen Funktionszeiger zu konvertieren.
Vinícius A. Jorge
28

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 stets 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 wie Java interessiert (dh Sie arbeiten in einem "Java-Shop"). Ihre Wahl der Technologie hängt möglicherweise von dem Ökosystem ab, in dem Sie entwickeln, z. B. von sprachspezifischen APIs. In solchen Fällen kann die Minimierung der Anzahl der Technologien von Vorteil sein.

Ein dritter Grund, den ich mir vorstellen kann, ist, dass Qt auf C ++ basiert und C ++ eine vergleichsweise schwierige / gefährliche Programmiersprache ist. Ich denke, es ist eine Sprache für Profis. Wenn Sie Spitzenleistung benötigen und in der Lage sind, akribisch zu sein, ist C ++ wahrscheinlich immer noch das beste Spiel der Stadt. Tatsächlich verbessert Qt viele der Speicherverwaltungsprobleme, wenn Sie festlegen, dass Dinge außerhalb des Bereichs fallen. Außerdem leistet Qt selbst gute Arbeit, indem es den Benutzer von vielen unangenehmen C ++ - Problemen isoliert. Jede Sprache und jeder Rahmen hat Vor- und Nachteile. Es ist ein sehr, sehr kompliziertes Thema, das sich in der Regel durch die Addition zusammenfassen lässt, die häufig bei Gästen zu finden ist: Geschwindigkeit, Qualität und Preis (Sie können jedoch nur zwei auswählen).

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

  1. Qt ist in der Tat eine C ++ - Bibliothek / Framework / Header-Dateien. Es ist erweitertdurch einen Makroprozessor (moc), der unter anderem Signale und Slots ermöglicht. Es transformiert zusätzliche Makrobefehle (wie Q_OBJECT), sodass Klassen eine Selbstbeobachtung und alle möglichen anderen Extras haben, die Sie möglicherweise als Hinzufügen von Objective-C-Funktionalität zu C ++ betrachten. Wenn Sie genug über C ++ wissen, um von diesem Mangel an Reinheit beleidigt zu werden, dh, Sie sind ein Profi, dann 1) verwenden Sie Q_OBJECT und seine Eigenschaften nicht oder 2) seien Sie dankbar, dass es dies tut, und programmieren Sie um die sehr begrenzten Eckfälle herum 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 genannten Probleme wie schlechte Dokumentation, horrende APIs und plattformübergreifende Horrors (denken Sie an alte Compiler wie gcc 3).

  2. Für die Editorunterstützung ergibt sich dies auch aus 1, da stimme ich einigermaßen zu. Tatsächlich ist Qt Creator meiner Meinung nach der beste grafische C ++ - Editor, auch wenn Sie das Qt-Zeug nicht verwenden. Viele professionelle Programmierer verwenden Emacs und Vim. Ich denke auch, dass Eclipse die zusätzliche Syntax handhabt. Somit keine Probleme mit den Qt-Makros (Q_OBJECT) oder Signal / Slot-Zusätzen. Sie werden diese Makros wahrscheinlich nicht in Visual Studio finden, da sie (wie ich zugebe) Ergänzungen zu C ++ sind. Aber im Großen und Ganzen werden C # /. NET-Leute Qt ohnehin nicht verwenden, da sie einen Großteil der Funktionen haben, die mit ihren eigenen proprietären Techniken abgedeckt werden.

  3. Wen interessiert es, wie groß die Qt-Quelle ist, solange sie über Nacht kompiliert wird? Ich habe Qt 4 auf meinem Dual-Core-Macbook in "weniger als über Nacht" kompiliert. Ich hoffe sicherlich, 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 Varianten möglich: 1) Proprietäre Lizenz für den Fall, dass Sie Qt ITSELF ändern und nicht freigeben möchten oder die Tatsache verbergen möchten , dass Qt verwendet wird und nicht bereit ist, Angaben zu machen (kann für Branding und Image sehr wichtig sein!). 2 ) GPL und 3) LGPL. Ja, es gibt Probleme mit statischen Verknüpfungen (alle Qt in die Binärdatei rollen) - aber ich denke, das ist mehr, weil man nicht hineinschauen kann und merkt, 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 sie wirklich nicht." Beeindruckend. Von einem Unternehmen, das Lizenzen verkauft.

  5. Die Größe des Binarys / Bundles liegt daran, dass Sie das Qt-Zeug 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 mit der Verteilung der ~ 50 Megabyte großen statischen Datei (die ich mit einigen binären Stripper- / Komprimierungsprogrammen wie UPX noch verkleinern kann). Ich kümmere mich einfach nicht genug darum, aber wenn Bandbreite jemals ein Problem wäre, würde ich meinem Build-Skript einen UPX-Schritt hinzufügen.

  6. Was bedeutet "Natives Aussehen und Gefühl"? 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 und sie sehen nicht gleich aus, 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 dies 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 annehmen könnte.

Eric Brown
quelle
1
Was ich nicht verstehe, ist, warum diese plattformübergreifenden Bibliotheken nicht einfach Wrapper-Funktionen sind oder noch besser. Wenn Probleme mit Cocoa, Win32, KDE / Gnome auftreten, wird die bestaussehende Benutzeroberfläche mit all ihren Funktionen sichergestellt.
MarcusJ
2
@MarcusJ Einen Wrapper um ein Toolkit zu schreiben ist ausgesprochen nicht trivial, egal ob 4 oder mehr - aber wenn Sie der Meinung sind, dass es so einfach ist, können Sie es gerne versuchen. Was die Idee betrifft, dass dies nur mit einer bedingten Vorverarbeitung erreicht werden kann ... Sie müssen scherzen, oder?
Underscore_d
@MarcusJ libui ist genau das (allerdings ohne KDE-Unterstützung).
Demi
Ich möchte hinzufügen, dass Sie jetzt Qt / QML mit .NET verwenden können. Sie müssen C ++ nicht berühren. github.com/qmlnet/qmlnet PS: Ich bin der Autor.
Paul Knopf,
26

Ein Teil davon ist Lizenzierung. Unter https://en.wikipedia.org/wiki/Qt_(software)#Licensing finden Sie Informationen zum Lizenzverlauf. Bis zum Jahr 2000 nutzten 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 Leute, 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 keine Möglichkeit, Qt zu verwenden. Daher kann kein freies Softwareprojekt, das älter als diese Daten ist, Qt verwenden. Und natürlich mussten Leute, die proprietären Code schrieben, für das Privileg bezahlen.

Darüber hinaus ist es nicht so, dass es an anderen Optionen mangelt. Zum Beispiel WxWidgets , GTK + und Tk sind alle Open Source, Cross-Plattform - Toolkits.

Außerdem war Windows auf dem Desktop lange Zeit so dominant, dass eine Menge Software nur unter Windows ausgeführt werden konnte. Wenn Sie die Microsoft-Toolchain installieren, ist es einfacher, das proprietäre Material von Microsoft zu verwenden, als sich um alles andere zu kümmern, und viele Programmierer haben genau das getan.

btilly
quelle
1
@btilly: GTK + ist plattformübergreifend. Beispielsweise ist der Pidgin IM-Client in GTK + geschrieben.
Billy ONeal
1
Ok, aber es ist irgendwie möglich, unter Windows zu laufen :)
Dehumanizer
6
Einfach GIMP unter Windows installieren und reinschauen.
user281377
2
Ja, und GIMP funktioniert gut unter Windows, passt aber mit Sicherheit nicht zum Erscheinungsbild der Windows 7-Benutzeroberfläche.
Alan B
5
Pidgin ist wahrscheinlich ein besseres Beispiel für GTK unter Windows. Es ist nichts Besonderes, aber es passt und hat vielleicht 10 Jahre oder länger?
Brendan Long
14

Ich stimme fast allen oben diskutierten Gründen zu, aber viele Leute hier haben gesagt, sie würden Qt nicht verwenden, weil es zusätzlichen Overhead mit sich bringt. Ich bin damit nicht einverstanden, weil 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, die es verwendet, wieder wettmacht. Ich bin auf eine ganze Reihe von Konsolenanwendungen gestoßen, die in Qt und nicht in Standard-C ++ geschrieben wurden, weil sie einfach zu schreiben sind.

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

WKS
quelle
2
Ich denke, es hängt alles von der Erfahrung des Einzelnen ab, da ich in C ++ 14 gut codieren kann, aber jedes Mal, wenn ich auf einen Qt-Code schaue, muss ich hart schielen, um ihn als dieselbe Sprache zu erkennen ... also ziehe ich ihn auf jeden Fall an Ich glaube nicht, dass dies der einhellige Produktivitätsschub ist, den Sie hier implizieren.
Underscore_d
1
@underscore_d Wenn Sie C ++ sehr gut kennen und Qt nicht, werden Sie mit letzterem offensichtlich nicht produktiver sein. Aber wenn Sie sowohl C ++ als auch Qt kennenlernen, macht das Framework viele Dinge einfacher und schneller zu implementieren (C ++ 11, 14 usw. füllen die Lücke, aber noch nicht vollständig).
ymoreau
11

Dies ist wirklich kein Versuch, einen Flammenkrieg auszulösen, ich wollte nur einige der Punkte ansprechen.

Wahrscheinlich ist der wahre Grund dafür, dass Qt nicht so verbreitet ist, dass es C ++ ist und weniger Menschen C ++ für Desktop-Apps verwenden.

Qt ist keine C ++ - Bibliothek. Es ist ein separater Kompilierungsschritt erforderlich, wodurch der Erstellungsprozess im Vergleich zu den meisten anderen Bibliotheken viel komplizierter wird.

Das vs-Addin für Visual Studio erledigt dies automatisch, ebenso wie Qts eigener Kommandozeilen-Make-Prozess. 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 Quellcode, die auf jedem Computer vorhanden und vorinstalliert sein muss, den Sie verwenden, bevor Sie kompilieren. Dies kann das Einrichten einer Build-Umgebung erheblich erschweren.

Es gibt einen binären Download für jede Version von Visual Studio und der Build aus dem Quellcode ist ein einziger Befehl. Ich sehe nicht, dass die Größe der SDK-Quelle heutzutage so wichtig ist. Visual Studio installiert jetzt alle C ++ - Bibliotheken und lässt Sie nicht mehr auswählen. Daher ist die Installationsgröße des Compilers> 1 GB.

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

Die LGPL bezieht sich nur auf die Bibliothek, nicht auf Ihren Code. Ja, es bedeutet, dass Sie DLLs anstatt einer einzelnen Binärdatei ausliefern müssen (es sei denn, Sie zahlen dafür), aber in einer Welt, in der Sie eine Java-Laufzeit oder ein .Net-Update für eine winzige Anwendung herunterladen müssen, ist dies keine so große Sache. Auf Plattformen mit einem einzigen ABI ist dies auch weniger problematisch, sodass andere Qt-Apps die Bibliotheken gemeinsam nutzen können.

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

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

Martin Beckett
quelle
1
Sehr viele große Softwareunternehmen erstellen kommerzielle Anwendungen in C ++, aber mir sind nicht viele bekannt, die QT verwenden. Obwohl ich verstehe, dass Nicht-C ++ - Entwickler QT vermeiden könnten, gibt es andere Gründe, QT zu vermeiden, auch wenn Sie eine C ++ - App schreiben. Tatsächlich gibt es wirklich keine plattformübergreifende Sprache und kein GUI-Toolkit, an dem ich nichts auszusetzen habe. Es scheint, dass die plattformübergreifende Entwicklung NUR EINFACH SCHWER ist, und dass es niemals einfach oder kostenlos ist, es gut zu machen, und dass das Versprechen von QT (Schreiben Sie Ihre GUI einmal und verwenden Sie diese GUI überall wieder) nicht ausreicht.
Warren P
Die meiste Desktop-C ++ - Software ist entweder in MFC enthalten, weil sie vor 20 Jahren gestartet wurde, oder verwendet ein internes Toolkit, das vor 20 Jahren gestartet wurde, um MFC zu vermeiden (z. B. MS-Office oder Autocad). Ich bezweifle, dass mit WPF sehr viel in C ++ / CLR geschrieben wird. Aber auch ohne plattformübergreifende Überlegungen finde ich Qt das beste (oder am wenigsten schlechteste!) Desktop-Toolkit. Wie die meisten Leute bewegen wir uns in Richtung eines Webby-Frontends (möglicherweise in QtQuick / QML) und eines C ++ - Server-Backends, das wahrscheinlich Qt-Signale / -Slots, aber keine GUI verwenden wird
Martin Beckett
Genau. Am schlimmsten. Und selbst in Windows-Apps würde ich eher QT-Probleme als MFC-Probleme beheben.
Warren P
@WarrenP - ja, ich vermisse es nicht, das Codeprojekt nach all dem Zeug zu durchsuchen, das in MFC fehlt. Mit MSFTs neuer Liebe zum nativen Code haben sie jedoch nicht viel getan, um das Schreiben einer GUI zu vereinfachen.
Martin Beckett
7

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

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

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.

Leichtigkeitsrennen im Orbit
quelle
1
Qt bietet jedoch die Möglichkeit, nur Konsolenanwendungen zu schreiben. Ist es nicht
Dehumanizer
9
@ Dehumanizer: Ich habe keine Ahnung. Aber warum sollte ich es für ein kleines Hilfsprogramm verwenden? Welchen Nutzen würde mir das bringen, wenn ich die Anwendung einfach in Standard-C ++ schreiben kann? Anscheinend suchen Sie nach einem Grund, eine Bibliothek zu verwenden.
Leichtigkeitsrennen im Orbit
12
@ Dehumanizer: Wie gesagt, das ist ein Rückwärtsansatz. Wenn Sie eine Bibliothek benötigen, wissen Sie Bescheid, und dann können Sie ein paar davon ausprobieren und herausfinden, was besser zu Ihnen passt. Der Versuch, eine Meinung zu einer Bibliothek zu sammeln, wenn Sie keinen Anwendungsfall haben, ist ein Kinderspiel.
Leichtigkeitsrennen im Orbit
3
"Wenn ich eine einfache Befehlszeilenanwendung schreibe, warum sollte ich das mit Qt aufblähen, nur um es zu verbessern?" Es gibt mindestens ein sehr berühmtes Nicht-GUI-Tool in Qt - Doxygen :-)
Valentin Heinitz
4
@Dehumanizer zum Beispiel, wenn Sie mit Dateien, XML, Unicode, JSON, RegExp, Concurency, Datenbanken usw. usw. sehr schnell umgehen müssen und keine Dutzend Bibliotheken von Drittanbietern herunterladen, adoptieren und warten möchten.
Valentin Heinitz
5

Frameworks wie Qt sind geeignet, wenn Sie sich mehr darum kümmern, dass Ihr Produkt auf allen Plattformen gleich aussieht, als dass Ihr Produkt auf allen Plattformen richtig aussieht. Heutzutage werden solche Anwendungen immer häufiger auf webbasierte Technologien umgestellt.

Caleb
quelle
4

Ich stimme zu, dass Qt ein guter Rahmen ist, mit dem man arbeiten kann. Dennoch gibt es eine Reihe von Problemen, die ich damit habe:

  1. Es ist in C ++ geschrieben, einer wirklich einfachen Sprache. Allein die Tatsache, dass es sich um C ++ handelt, führt dazu, dass jeder Qt-Programmierer im Vergleich zu Frameworks, die in anderen Sprachen geschrieben wurden, erheblich weniger produktiv ist. Mein Hauptproblem bei C ++ als GUI-Entwicklungssprache ist, dass es so gut wie keine Vorstellung von automatischer Speicherverwaltung gibt, was den Entwicklungsprozess sehr viel fehleranfälliger macht. Es ist nicht introspektiv, was das Debuggen erheblich erschwert. Die meisten anderen wichtigen GUI-Toolkits haben eine Vorstellung von automatischer Speicherverwaltung und Introspektion.
  2. Jedes plattformübergreifende Toolkit hat das Problem, dass es nur den kleinsten gemeinsamen Nenner aller unterstützten Plattformen implementieren kann. Dies und unterschiedliche Richtlinien für die Benutzeroberfläche auf verschiedenen Plattformen stellen die Attraktivität von plattformübergreifenden GUIs insgesamt in Frage.
  3. Qt ist sehr darauf ausgerichtet, Ihre gesamte Benutzeroberfläche zu codieren. Auch wenn Sie können QtDesigner verwenden einige Teile Ihrer UI zu bauen, wird es fehlt ernst im Vergleich zu, sagen wir, (Cocoa / Obj-C) Interface Builder oder .NET - Tools.
  4. Obwohl Qt viele Funktionen für Anwendungen auf niedriger Ebene enthält, kann es nicht mit einem Framework verglichen werden, das von Hand auf eine bestimmte Plattform zugeschnitten ist. Die nativen Betriebssystembibliotheken für Windows und OSX sind wesentlich leistungsfähiger als die Implementierungen von Qt. (Denken Sie an Audio-Frameworks, Dateisystemzugriff auf niedriger Ebene usw.)

Ich liebe 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 zu einem sehr angenehmen Ort.


Bearbeiten Sie als Antwort auf einige Kommentare:

Als ich darüber schrieb, dass Qt in C ++ geschrieben wurde, habe ich mich nicht so sehr über Qt selbst beschwert, sondern über die Umgebung, in der es lebt. Es ist wahr, dass Qt seine eigenen Ressourcen sehr gut verwaltet, aber all Ihre GUI-bezogenen, aber not-Qt-Code muss auch in C ++ geschrieben werden. Auch dort bietet Qt viele nützliche 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 die Selbstbeobachtung betrifft, meine ich Folgendes: Die schwierigsten Fehlerbehebungsfälle sind, wenn Sie einen Zeiger auf ein Objekt haben, das sich nicht so verhält, wie Sie es sich vorstellen. In C ++ kann Ihr Debugger möglicherweise ein wenig in dieses Objekt hineinsehen (wenn es an diesem Punkt zufällig Typinformationen enthält), aber selbst das funktioniert nicht immer. Nehmen Sie auf der anderen Seite Kakao in der gleichen Situation. In Cocoa / Obj-C können Sie Nachrichten ("Aufruffunktionen") direkt innerhalb des Debuggers 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 erheblich vereinfachen. Qt / C ++ hat nichts in der Nähe.

Bastibe
quelle
11
1. Um die Speicherverwaltung selbst zu erledigen, müssen Sie nicht nach jedem 'Neu'-Vorgang' Löschen 'aufrufen. 1a. C ++ ist KEINE einfache Sprache, sondern eine Hochsprache mit geringen Fähigkeiten. 3. Ich bin damit einverstanden, aber Qt bietet an, eine Benutzeroberfläche mit QtDesigner und gleichzeitig mit 'einfachem Code' zu erstellen. 4. Stimmen Sie erneut zu, aber Qt bietet auch die Verwendung nativer APIs an.
Dehumanizer
11
Ich denke, C ++ hat eine Art halbautomatisches Speichermanagement: Wenn Sie intelligente Zeiger wie std :: auto_ptr oder boost :: shared_ptr usw. verwenden, müssen Sie sich im Allgemeinen nicht darum kümmern, Speicher freizugeben. Diese Art von Containern kann auch für andere Ressourcen (Dateien, freizugebende Systemressourcen) erstellt werden. Die Verwendung des RAII-Musters hilft sehr bei der Speicherverwaltung und da es in Sie hineinwächst, müssen Sie sich nicht wirklich um das Gedächtnis sorgen.
Deo
8
"Allein die Tatsache, dass es sich um C ++ handelt, wird jeden Qt-Programmierer im Vergleich zu Frameworks, die in anderen Sprachen geschrieben wurden, erheblich weniger produktiv machen." [Zitieren benötigt]
Nathan Osman
4
@ SK-logic: Während ich denke, dass ich alle Wörter in deinem dritten Satz verstehe, habe ich keine Ahnung, was du sagst. Was ist ein "Level of Abstraction Cap"? Dein erster Satz ist in Anbetracht der Wikipedia-Definition von "Low-Level-Sprache" falsch.
David Thornley
6
@ SK-logic: Die Template-Metaprogrammierung ist Turing-vollständig, und es gibt Leute, die klug und kenntnisreich genug sind, um davon zu profitieren. RAII ist keine großartige Speicherbereinigung, aber die Tatsache, dass es für alle Arten von Ressourcen funktioniert, macht das mehr oder weniger wett. Was für eine Art von Abstraktion funktioniert nun in Java, aber nicht in C ++?
David Thornley
3

Ich mag Qt sehr, aber es ist ein bisschen schwergewichtig für viele Anwendungen. Manchmal braucht man einfach nicht so viel Komplexität. Manchmal braucht man nur 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 ausführt.

Für andere Anwendungen gelten Lizenzanforderungen, die mit der GPL, LGPL oder der kommerziellen Lizenz von Qt nicht kompatibel sind. 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ätsaspekte, die komplexe Bibliotheken wie Qt nicht zulassen.

Sie müssen moc ausführen, um Ihre Quellen vorab zu verarbeiten. Das ist kein großes Problem, aber für den neuen Benutzer kann es entmutigend sein. Viele Programmierer denken Sie müssen mit Qt verwenden qmake, aber das ist eine falsche Bezeichnung. Es ist sehr 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 darauf stoßen und sich fragen, was los ist.

Es ist nur C ++. Es gibt andere Sprachbindungen, aber sie verbergen häufig die Funktionen, für die Sie Qt benötigen, oder machen sie nur unzureichend verfügbar.

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

Adam Hawes
quelle
3

Das Wichtigste, aber nicht Erwähnte. In großen Projekten verursacht eine Sache so viele Probleme und unnötigen Code. Die Signalschlitzmechanismen von Qt sind ineffizient. Qt-Widgets liefern keine erforderlichen Signale für einfache Ereignis-Widgets. 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 mit benutzerdefiniertem Ereignis eine neue Klasse erstellt. Dies ist ein enormer Effizienzverlust.

  • Sie haben jedes benutzerdefinierte Widget-Objektereignis umgeschrieben. Es gibt kleine Änderungen.
  • Sie verlieren alle Qt Designer-Sachen. Sie müssen jedes Widget mit benutzerdefinierten Ereignissen bewerben.
  • Projekt wurde größer und schwer zu pflegen.
  • Sie haben deshalb angefangen, qt nicht zu mögen. Und wir fangen an darüber zu sprechen, wie .net Delegierten zur Verfügung stellt, wie es viel, viel besser ist als der Signalsteckplatz, wie .net-Komponenten (Widgets) im Allgemeinen jedes Ereignis bereitstellen, das Sie sich vorstellen können. Und soweiter und sofort.

Einer meiner Studenten hat für jedes Kombinationsfeld-Widget eine neue Kombinationsfeld-Klasse geschrieben, weil er ein Nicht-Signal-Ereignis verwenden musste. Wahre Geschichte...

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

Obrix
quelle
Ereignisse betrachten und neue Klassen erstellen: Sie können Ereignisfilter in Klassen verwenden, die darauf reagieren müssen.
MrFox
"Ja, Sie können Ereignisse verwenden, ABER !!! Sie haben für jedes Widget mit benutzerdefiniertem Ereignis eine neue Klasse erstellt. Dies ist ein enormer Effizienzverlust." - NICHT GENAU. Ich lande einfach bei bool eventFilter, das mehrere Widgets verarbeitet, und installiere dannEventFilter (this) auf allen untergeordneten Widgets. Dabei gehen Effizienz und Programmierleistung nicht verloren! Eigentlich verwende ich niemals "gesponserte Widgets" ... Ich lasse einfach ein leeres Widget fallen, installiere es als eventFilter und implementiere die meisten meiner Ereignisse in meiner Hauptklasse cpp neu. Versuchen Sie es, nicht Schmerz :) Sie können fast alles in Qt anpassen , ohne neue Klassen zu schaffen , jedes Mal
Петър Петров
3

Meiner Meinung nach ist es einfacher, C ++ - Programmierung zu lernen, 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 ++ und ist damit höher als natives C ++. Somit ist Qt C ++ ein großartiges Framework für diejenigen, die auf die gleiche Art und Weise Aufgaben auf niedriger oder hoher Ebene entwickeln möchten. C ++ ist (nach einigen Methoden) eine komplexe und einfache Sprache. Komplex für diejenigen, die es nicht herausfordern wollen, einfach für diejenigen, die es mögen. Lassen Sie es nicht zu komplex!

user100691
quelle
2

Der eigentliche Grund ist nicht technisch.

Menschen sind zufällig anders. So sind ihre Entscheidungen. Homogenität ist kein menschliches Merkmal.

mouviciel
quelle
Gehen deshalb alle Menschen auf den Beinen? Nun, diejenigen, die mindestens Beine haben ...
dtech