man ist sich einig, dass qt evil ist
-
Hi. In #cpp Channel auf euirc hab ich von MrN gelesen:
"man ist sich einig, dass qt evil ist"Was ist eure Meinung dazu?
Hatte davor noch nichts davon gehört das QT schlecht ist.
Aber MrN hat glaube ich mehr Ahnung als ich.
-
Cool. Naja, aber bitte keinen allzu schlimmen Flamewar.
Qt is vor allem deswegen evil weils einen MOC benutzt und QT-Code kein C++ ist. Und das obwohl es in C++ ginge. Außerdem benutzt Qt keine Namespaces. Qt ist zu gute zu halten, dass es älter ist als das moderne C++.
Wäre ich ein Hardcore-OSSler würde ich Trolltechs Politik bei Qt für Windows bemängeln. Bin ich aber nicht.
Qt ist schneller als GTK2
. Aber ich benutz allein schon weils für GTK+ mehr geile Skins gibt (naja, eigentlich vor allem nur andere) eher GTK+ - von den Programmen her die ich benutze.
Meine 2 cent.PS: ChrissiC++ ist wer?
-
Mr. N schrieb:
PS: ChrissiC++ == ChrissiB oder wer?
Nein, ich poste (eigentlich) nur registriert und mit richtigen Namen
-
trolltechs windows politik is, dass man für die non-commercial n buch kaufen muss...
kann ich verkraftenich mag an qt dass techniken wie drag&drop, toolbars, dockwindows
verdammt einfach zu programmieren isbei win fand ich das immer soooo umständlich
und mit dem signal/slot konzept lassen sich in eigenen klassen auch nette sachen umsetzen
negativ find ich dass ausser den headern nich das kleinste bischen quellcode dabei is
man kann im gegensatz zu mfc nichmal eine oder zwei stufen reinsteppen
-
@Sovok: Juchuu! Welches Buch?
-
Nein eigentlich nicht. Was für ein buch 0_o
Es ist doch so, das es für Linux eine Kostenlose version gibt und für Windows gibts nur ne alte version kostenlos. Für kommerzielle Software muss man sie lizensieren. Ausserdem muss das Prog mit der freien Version von QT unter der GPL veröffentlicht werden.
-
Ichie schrieb:
@Sovok: Juchuu! Welches Buch?
http://www.amazon.de/exec/obidos/ASIN/0131240722/qid=1092941698/ref=sr_8_xs_ap_i1_xgl/028-6933022-8478909
C++ GUI Programming with Qt3 | ISBN: 0131240722
-
das denken jedenfalls die meisten :p
ich hab auch erst auf qtforum.org davon erfahren
Kurzbeschreibung
Straight from Trolltech, this book covers all one needs to build industrial-strength applications with Qt 3.2.x and C++--applications that run natively on Windows, Linux/UNIX, Mac OS X, and embedded Linux with no source code changes. Includes a CD with the Qt 3.2 toolset and Borland C++ compilers--including a noncommercial Qt 3.2 for Windows available nowhere else.
-
Sovok schrieb:
und mit dem signal/slot konzept lassen sich in eigenen klassen auch nette sachen umsetzen
Signal/Slots bietet auch die libsigc++, die z. B. gtkmm benutzt, aber mit NATIVEM C++, da muss ich nichts mehr durch den MOC jagen. Von daher ist das IMO auch kein Argument fuer Qt.
GEGEN Qt spricht auch, dass Qt 4 (soweit ich das bis jetzt aus der trolltech-Doku rauslese) diese großen Mankos nicht ausmaerzt: immer noch keine Namespaces und der MOC wird immer noch benutzt (zumindest haett ich keinen Hinweis darauf gefunden, dass er abgeschafft wird).
Sollt ich mich irren/was in der Doku ueberlesen haben, dann moege man mich bitte korrigieren!
-
das ein moc benutz wird oder das es nicht das aller neuste c++ ist sollte echt kein grund sein diese lib nicht zu benutzen, seid ihr erst zufrieden wenn eine lib ale halbe jahre ihre schnittstelle umkrempelt?
wenn ihr so auf standard c++ aus seid, dann schreibt doch ein wrapper um die slots/signals von qt, dann könnt ihr standard c++ code, das es kein sinn hat dabei standard c++ zu coden ist egal (weil ihr sowieso abhänig von der lib seid)
-
Hallo,
würde mir mal einer erklären, was das Problem am MOC ist? Klar man kann Signals- und Slots auch mit Templates verwirklichen, aber der MOC bietet einem ja mehr. Die "Reflection"-Eigenschaften bekommt man z.B. nicht so ohne weiteres über Templates. Desweiteren würde eine Template-Lösung erstmal wieder eine Menge Kunden ausschließen (solche mit älteren Compilern). Außerdem ist die Geschichte mit dem MOC viel flexibler. Aber Argumente für den MOC findet man gut ausformuliert ja auch in der Qt-Doku.Ich persönlich finde die Qt im Punkto benutzbarkeit sehr gelungen. Und dank qmake bzw. VC-Integration hatte ich auch noch nie irgendein Problem mit dem MOC. Ist eine automatisch integrierte Buildstufe und aus diesem Grund überhaupt nicht störend.
Die Aussage:
"man ist sich einig, dass qt evil ist"
stimmt nur für eine sehr eingeschränkte Belegung von "man".
Aber MrN hat glaube ich mehr Ahnung als ich.
Vielleicht. MrN neigt aber auch immer gerne zu einem Generalanspruch. In diesem Punkt eifert er imo etwas zu unkritisch seinem Mentor nach
(wobei mich Volkards Meinung zu diesem Thema da doch glatt mal interessieren würde).@Mr.N
Die für den Kunden wahrnehmbare Qualität eines C++ Softwareprodukts wird nicht unbedingt durch die Anwendung von "cutting-edge" C++-Techniken erhöht. Insofern halte ich dein Argument aus Sicht des Standard-Anwenders für blödsinn. Der Anwender einer GUI-Bibliothek (zumindest der, der sich nicht nur so aus Spass mit einer solchen Lib beschäftigt) legt vielmehr Wert auf gute Tools (Qt Designer, Linguist ...), eine einfache Programmierschnittstelle, gute Dokumentation usw.der MOC wird immer noch benutzt (zumindest haett ich keinen Hinweis darauf gefunden, dass er abgeschafft wird).
Der wird mit Sicherheit nicht abgeschafft. Trolltech sieht im MOC einen Vor- und keinen Nachteil. Der MOC wird nur immer weiterentwickelt. Und am Ende kommen dabei dann immer bessere Tools heraus.
-
Blue-Tiger schrieb:
Sovok schrieb:
und mit dem signal/slot konzept lassen sich in eigenen klassen auch nette sachen umsetzen
Signal/Slots bietet auch die libsigc++, die z. B. gtkmm benutzt, aber mit NATIVEM C++, da muss ich nichts mehr durch den MOC jagen. Von daher ist das IMO auch kein Argument fuer Qt.
gtkmm is was für linux entwickler
mit vc++ hab ichs noch nie gescheit zum laufen gebrachtqt dagegen hat sogar ein sehr nützliches vc addin
-
HumeSikkins schrieb:
Hallo,
würde mir mal einer erklären, was das Problem am MOC ist? Klar man kann Signals- und Slots auch mit Templates verwirklichen, aber der MOC bietet einem ja mehr. Die "Reflection"-Eigenschaften bekommt man z.B. nicht so ohne weiteres über Templates. Desweiteren würde eine Template-Lösung erstmal wieder eine Menge Kunden ausschließen (solche mit älteren Compilern). Außerdem ist die Geschichte mit dem MOC viel flexibler. Aber Argumente für den MOC findet man gut ausformuliert ja auch in der Qt-Doku.[....]
Der wird mit Sicherheit nicht abgeschafft. Trolltech sieht im MOC einen Vor- und keinen Nachteil. Der MOC wird nur immer weiterentwickelt. Und am Ende kommen dabei dann immer bessere Tools heraus.
ich sah im MOC eigentlich immer nur ein Tool, das Signals/Slots erlaubt, alles andere ist mir neu, klaer mich mal auf
trotzdem nervt mich der Zwischenschritt ( <== Disclaimer: das, und alles was jetzt folgt sind lediglich PERSOENLICHE MEINUNG
). Die Integration ins MSVS moegen ja gut sein, aber nicht jeder benutzt das Visual Studio. Als Dev-C++ User sitzt man auf dem Trockenen und muss selbst Hand anlegen. Ist IMO genau das Selbe wie Sovoks Meinung zu gtkmm. Das funktioniert halt mit dem Dev-C++ besser als mit dem VC... (wie gut ist denn Qt eigentlich in den BCB integrierbar?)
Dass "modernes" C++ kein Muss ist und man auch ohne gut auskommt ist mir vollkommen klar. Aber z. B. das Nutzen von namespace's zu integrieren ist IMO eine triviale Aufgabe, der Nachzukommen Qt versaeumt hat. Klar, es funktioniert auch ohne, es waer halt "schoen gewesen"EDIT: und dass ich mir ein Buch um 50 Euro kaufen muss, um an eine Library zu kommen, die sich selbst als "frei" bezeichnet, ist fuer mich ein moralischer Wiederspruch
-
Blue-Tiger schrieb:
HumeSikkins schrieb:
Hallo,
würde mir mal einer erklären, was das Problem am MOC ist? Klar man kann Signals- und Slots auch mit Templates verwirklichen, aber der MOC bietet einem ja mehr. Die "Reflection"-Eigenschaften bekommt man z.B. nicht so ohne weiteres über Templates. Desweiteren würde eine Template-Lösung erstmal wieder eine Menge Kunden ausschließen (solche mit älteren Compilern). Außerdem ist die Geschichte mit dem MOC viel flexibler. Aber Argumente für den MOC findet man gut ausformuliert ja auch in der Qt-Doku.[....]
Der wird mit Sicherheit nicht abgeschafft. Trolltech sieht im MOC einen Vor- und keinen Nachteil. Der MOC wird nur immer weiterentwickelt. Und am Ende kommen dabei dann immer bessere Tools heraus.
ich sah im MOC eigentlich immer nur ein Tool, das Signals/Slots erlaubt, alles andere ist mir neu, klaer mich mal auf
Der MOC ist für das gesamte Meta Object System zuständig.Dazu gehören neben Signals/Slots so Sachen wie Properties, Internationalisierung, erweiterte RTTI-Unterstützung (-> Meta-Object)
Lies doch einfach mal ein bischen in der Qt-Doku, falls es dich interessiert.http://doc.trolltech.com/3.3/templates.html
http://doc.trolltech.com/3.3/object.html
http://doc.trolltech.com/3.3/metaobjects.htmltrotzdem nervt mich der Zwischenschritt
Nervt dich auch das Linken beim C++ Programmieren? Von dem Zwischenschritt MOC bekommst du doch gar nichts mit. Du schreibst deine Klassen, lässt qmake laufen und fertig. Das da zwischendurch auf der Konsole ein "moc'ing xyz" oder "uic'ing abc" steht, wo ist das Problem?
Als Dev-C++ User sitzt man auf dem Trockenen und muss selbst Hand anlegen
Wirklich so schlimm? Verstehe ich ehrlich gesagt nicht. Dank des qmake-Tools kann das moc'ing vollständig automatisch ablaufen. Wenn die IDE/Editor es also erlaubt statt make qmake aufzurufen, brauchst du auch nichts von Hand zu machen. So mache ich das z.B. unter Linux immer.
(wie gut ist denn Qt eigentlich in den BCB integrierbar?)
Es gibt eine Qt-Integration für Borland. Wie gut die ist, weiß ich allerdings nicht.
Aber z. B. das Nutzen von namespace's zu integrieren ist IMO eine triviale Aufgabe, der Nachzukommen Qt versaeumt hat. Klar, es funktioniert auch ohne, es waer halt "schoen gewesen"
Namespaces wären sicher schön. Das Hinzufügen selbiger wäre aber nicht trivial. Weder aus Clientsicht, da die alle ihre Qt-Programme ändern müssten, noch aus Trolltech-Sicht, da ich mal behaupten würde, dass eine solche Änderung auch Auswirkungen auf Tools wie den Moc hätte. Mit einfach überall namespace Qt hinschreiben ist es auf jeden Fall nicht getan. Auf der anderen Seite: Die Leute, die Qt einsetzen, sind sowieso bereits daran gewöhnt, dass Qt keine Namespaces benutzt, was hätten die wohl von einer Änderung? Und Leute die die Qt evaluieren werden sich sicher nicht nur deshalb gegen die Qt entscheiden, weil sie keine Namespaces verwendet.
Vom Kosten-Nutzen-Faktor scheint es mir deshalb logisch, dass Trolltech die Zeit lieber in neue Features investiert (-> Namespaces sind für eine GUI-Lib sicher kein Feature).EDIT: und dass ich mir ein Buch um 50 Euro kaufen muss, um an eine Library zu kommen, die sich selbst als "frei" bezeichnet, ist fuer mich ein moralischer Wiederspruch
Einen Widerspruch kann ich hier nicht entdecken. Das liegt vielleicht daran, dass ich nirgends auf der Trolltech-Seite einen Hinweis darauf finde, dass Trolltech die Qt als "frei" bezeichnet. Vielmehr wird da recht deutlich, dass Qt primär eine kommerzielle Lib ist, die man evaluieren kann damit man sieht, was für unglaubliche Produktivitätsvorteile man dank Qt hat (sprich: echtes Marketing)
*Zusätzlich* bieten sie halt noch die Qt/X11 als GPL-Version an. Die kommt aber z.B. ausdrücklich mit "with no support and no warranty".
-
Frage: Hab mich noch net so genau mit QT beschäftigt. Gibts sowas wie "QT Runtime Library" die man mit dem prog. mitliefern muss oder wird alles einkompiliert?