Obwohl ich Qt sehr gerne verwendet habe, bin ich nicht überzeugt, dass die dahinterstehende Technologie langfristig vernünftig ist. Das Präprozessor-Modell mit MOC erzeugt zwar gültigen C++-Code, die Vorgehensweise selbst ist aber letztlich technisch unsauber. Vor allem stammt das Konzept aus einer Zeit, als C++ noch ganz anders aussah, ohne Templates etc. Insofern ist Qt eben auch ein Legacy-Konzept.
Was mich an KDE stört, ist schlicht, dass man dort nicht Qt anwendet, sondern seinen eigenen Käse "drüberlayert". Über diese Desktop-Pestilenz namens "Plasma", die Aaron Seigo zu verbreiten sucht, rede ich mal jetzt lieber nicht.
Wenn Qt keine Firma mehr im Rücken hat, bzw. wieder proprietärer Code wird (und KDE dann auf BSD-Lizenz-Basis weitermachen muss), dann wird sich herausstellen müssen, wie stark das Backing der "community" ist. Da es ohnehin zuviele C++-Desktop-GUIs und zu wenig C++-Entwickler gibt, wird dann der Vorteil von Qt gut dokumentiert und benutzerfreundlich zu sein, schnell dahinschwinden, fürchte ich. So gesehen war der Verkauf von Trolltech an Nokia wirklich ein Unglück.
Es gibt eine lange Liste von Gründen gegen Templates: http://doc-snapshot.qt-project.org/4.8/templates.html
Mit der nächsten Version der kdelibs wird die Überlappung von Qt und KDE teilweise aufgelöst. Nützlich Klassen wandern dann in Qt. Natürlich wird Qt verwendet, aber ist gibt halt oft Dinge die so nicht in Qt vorhanden sind und von den kdelibs hinzugefügt werden z.B. KIO.
doch das gilt auch für den neuen Eigentümer. Der kann natürlich Qt nurnoch closed source weiterentwickeln wenn er möchte, der aktuelle Stand geht dann an die genannte Organisation und wird dann von dieser unter der BSD-Lizenz weiterentwickelt.
Aktuell kommen ca 40% der Beiträge von Entwickler, die nicht bei Nokia arbeiten: http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
Das mit den Templates habe ich auch mal geglaubt. Dein Gedankengang kann ich aber inzwischen nicht mehr nachempfinden. Templates sind sehr speziell auf eine bestimmte Art von Problemen zugeschnitten. Die Qt-Erweiterungen, die der MOC compilliert, sind jedoch sehr allgemeiner Art. Signals, Slots und der Connection-Mechanismus können sehr intuitiv verwendet werden als wären es C++ Befehle. Das bekommen Templates kaum so schön hin. Außerdem kommt man mit der Typisierung bei der Verwendung von Templates schnell ins Grübeln. Man muss sehr sauber arbeiten. Das ist natürlich ein Vorteil. Bei den Qt Signals und Slots möchte man jedoch flexibler sein und beliebege Signals mit beliebigen Slots verbinden, wenn die Signatur irgendwie passt. Das ist ein schwächer typisiertes System als es bei Templates üblich ist. Es geht um eine Sprach-Erweiterung. Das kann man auch klar so sagen. Und eine Sprach-Erweiterung erfordert einen Code-Generator.
Ich habe von KDE 0.9.x bis 4.0.x diesen Desktop genutzt, aber mittlerweile gibt es wenig, das mir mehr egal wäre, als das weitere Schicksal von KDE/Qt.
Obwohl ich Qt sehr gerne verwendet habe, bin ich nicht überzeugt, dass die dahinterstehende Technologie langfristig vernünftig ist. Das Präprozessor-Modell mit MOC erzeugt zwar gültigen C++-Code, die Vorgehensweise selbst ist aber letztlich technisch unsauber. Vor allem stammt das Konzept aus einer Zeit, als C++ noch ganz anders aussah, ohne Templates etc. Insofern ist Qt eben auch ein Legacy-Konzept.
Was mich an KDE stört, ist schlicht, dass man dort nicht Qt anwendet, sondern seinen eigenen Käse "drüberlayert". Über diese Desktop-Pestilenz namens "Plasma", die Aaron Seigo zu verbreiten sucht, rede ich mal jetzt lieber nicht.
Wenn Qt keine Firma mehr im Rücken hat, bzw. wieder proprietärer Code wird (und KDE dann auf BSD-Lizenz-Basis weitermachen muss), dann wird sich herausstellen müssen, wie stark das Backing der "community" ist. Da es ohnehin zuviele C++-Desktop-GUIs und zu wenig C++-Entwickler gibt, wird dann der Vorteil von Qt gut dokumentiert und benutzerfreundlich zu sein, schnell dahinschwinden, fürchte ich. So gesehen war der Verkauf von Trolltech an Nokia wirklich ein Unglück.
Es gibt eine lange Liste von Gründen gegen Templates: http://doc-snapshot.qt-project.org/4.8/templates.html
Mit der nächsten Version der kdelibs wird die Überlappung von Qt und KDE teilweise aufgelöst. Nützlich Klassen wandern dann in Qt. Natürlich wird Qt verwendet, aber ist gibt halt oft Dinge die so nicht in Qt vorhanden sind und von den kdelibs hinzugefügt werden z.B. KIO.
Erstens ist moc kein Präprozessor.
Zweitens ermöglichen Templates keine Introspektion. So etwas wie QML oder die dynamische Anbindung an dbus ist damit gar nicht möglich.
Drittens kann Qt gar nicht proprietärer Code werden, da es unter der LGPL steht.
> Drittens kann Qt gar nicht proprietärer Code werden, da es unter der LGPL steht.
Selbstverständlich kann Qt unter eine proprietäre Lizenz gestellt werden.
Währe ja noch schöner, wenn der Eigentümer sowas nicht dürfte.
Nur die bereits unter LGPL / GPL veröffentlichen Versionen kann dir keiner mehr nehmen.
Im Falle von Qt hat der Eigentümer aber einen Vertrag mit der KDE Free Qt Foundation:
http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php
Dadurch ist der Eigentümer zu LGPL 2.1 and the GPL 3 verpflichtet.
Sonst hätten die KDE-Leute in grauer Vorzeit nämlich irh eigenes Kt geschrieben, um dem Problem vorzubeugen (Stichwort Harmony).
Für den jetztigen Eigentümer, für neue Eigentümer muss das nicht gelten.
doch das gilt auch für den neuen Eigentümer. Der kann natürlich Qt nurnoch closed source weiterentwickeln wenn er möchte, der aktuelle Stand geht dann an die genannte Organisation und wird dann von dieser unter der BSD-Lizenz weiterentwickelt.
Der Vertrag besteht nur zwischen KDE und altem Eigentümer.
Qt ist ein Produkt und hat nichts mit Firmen zwischen zwei Organistationen zu tun.
Die Frage der Lizenz ist ein anderes Thema, andere Baustelle.
Korrektur:
Qt ist ein Produkt und hat nichts mit Verträgen zwischen zwei Organistationen zu tun.
Qt wird das durch das Qt Project (www.qt-project.org) entwickelt, das nicht das geringste Interesse hat, seine Lizenzierung zu ändern.
Was ein "Eigentümer" macht, hat darauf keinen Einfluss mehr.
> Was ein "Eigentümer" macht, hat darauf keinen Einfluss mehr.
Doch, denn der Eigentümer stemmt (fast) die gesamte Entwicklungsleistung.
Die sog. "Community" ist daran nicht beteiligt.
Nicht beteiligt würde ich nicht sagen.
Aktuell kommen ca 40% der Beiträge von Entwickler, die nicht bei Nokia arbeiten:
http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
Das mit den Templates habe ich auch mal geglaubt. Dein Gedankengang kann ich aber inzwischen nicht mehr nachempfinden. Templates sind sehr speziell auf eine bestimmte Art von Problemen zugeschnitten.
Die Qt-Erweiterungen, die der MOC compilliert, sind jedoch sehr allgemeiner Art. Signals, Slots und der Connection-Mechanismus können sehr intuitiv verwendet werden als wären es C++ Befehle. Das bekommen Templates kaum so schön hin. Außerdem kommt man mit der Typisierung bei der Verwendung von Templates schnell ins Grübeln. Man muss sehr sauber arbeiten. Das ist natürlich ein Vorteil. Bei den Qt Signals und Slots möchte man jedoch flexibler sein und beliebege Signals mit beliebigen Slots verbinden, wenn die Signatur irgendwie passt. Das ist ein schwächer typisiertes System als es bei Templates üblich ist.
Es geht um eine Sprach-Erweiterung. Das kann man auch klar so sagen. Und eine Sprach-Erweiterung erfordert einen Code-Generator.
Da cors!
Ich habe von KDE 0.9.x bis 4.0.x diesen Desktop genutzt, aber mittlerweile gibt es wenig, das mir mehr egal wäre, als das weitere Schicksal von KDE/Qt.
Schnee von Gestern.
Das wäre mir neu. Ich bin seit ca 2001 mal mehr mal weniger aktiv bei der KDE Entwicklung beteiligt, aber bisher habe ich da noch immer Qt benutzt.