Angesichts des KDE4-Debakels war ich mal auf reine Qt-Anwendungen umgeschwenkt und somit Qt-Fan.
Aber das war wohl der Sprung vom Regen in die Traufe. Irgendwelches marodes QtWebKit-Zeugs aus Qt-4.xx ist immer noch Grundlage von alternativen Browsern wie Netsurf oder Midori, und welche Bomben im nicht mehr gewarteten Qt 4.xx noch schlummern, weiss keiner.
Und wenn ich mir Qt 5.6 selbst kompiliere (bin Slackware-User), lade ich mir ein paar hundert (vermutlich unwartbare) MB Sourcen runter, die nach stundenlangem kompilieren in einem 50 MB grossen Blob landen.
Aber ist ja egal, der Kram wird in 2 oder 3 Jahren ohnehin weggeschmissen und durch ein paar GB Sourcen ersetzt, durch die erst recht keiner mehr durchblickt.
Auf Heise kann man täglich lesen, wie das Zeug den Leuten um die Ohren fliegt, aber es wird unentwegt auf den alten Müll immer mehr neuer Müll aufgetürmt. Und da es für die Smartphone-addicted-Kids nicht bunt und hip genug sein kann, geht es immer so weiter.
Es gibt Toolkits die sich schneller entwickeln und welche die sich langsamer entwickeln.
Die schneller entwickelnden Toolkits wie Qt und GTK+ werden schnell durch eine inkompatible neue Version ersetzt. Diese bietet aber mehr Features.
Toolkits wie das Fox Toolkit und FLTK werden ebenfalls kontinuerlich weiterentwickelt. Aber dort geht die Entwicklung langsamer voran. Dort kannst Du sicher noch immer 10 Jahre alten Quellcode gegen die aktuelle Version den Toolkits kompilieren. Aber dort gibt es auch kaum Neuerungen.
Und mit der fortschreitenden Entwicklung geschieht es automatisch, daß man merkt, daß es besser wäre einige grundlegende Dinge des Toolkits umzustrukturieren. Dadurch wird es zwar inkompatibel zu älteren Versionen, unterstützt dann aber auch neuere C++-Features.
Die Entwicklung wie sie sich entwickeln, ist bei allen Toolkits recht ähnlich. Nur die Geschwindigkeit in der es geschieht ist eine andere.
Ich werde wohl langsam zu alt für den Scheiss.
Dann nimm für Deine eigenen Projekte entweder ein Toolkit, das sich nur langsam entwickelt oder verwende das aktuelle Qt und bleib auch die kommenden Jahre bei der Version.
Von WebKit / Blink am Mi, 7. September 2016 um 08:11 #
Es gibt da große Probleme, die nicht in der Hand der Qt Entwickler liegen, sondern von Apple und Google verursacht worden sind.
Und zwar der Fork von WebKit (dem ursprünglichen KHTML) in Blink.
Früher (Qt 4.8) gab es sogar mal ein QWebKit für Android (von Bogdan Vatra). Heute gibt es auf Smatphones weder QWebKit noch Blink (QWebEngine) sondern nur noch QML Kram und das rudimentäre QTextBrowser.
Ich persönlich habe mich dazu entschieden nur den Widget orientierten Teil von Qt zu verwenden. Bei der Netzwerkkommunikation setze ich dierekt auf der Socket Bibliothek (Transportschicht) auf.
Graphische Experimente sind mittels SVG aber schön mit Qt zu realisieren. Leider fehlt dort inzwischen der WebKit basierte SVG Renderer und man muß bei QSvgRenderer bleiben.
Grundsätzlich habe ich die Erfahrung gemacht, dass man sich so wenig wie möglich auf fremde Bibliotheken stützen sollte. Es ist häufig sinnvoll sich auf die Verwendung der Posix Funktionen zu beschränken bzw. direkt auf Standard-Formaten bzw. Standard-Protokollen aufzusetzen.
Wichtiger als die Entwicklungsgeschwindigkeit eines Toolkits / Frameworks ist die Stabilität dessen Schnittstellen. Qt und speziell KDE hat sich nach KDE 4.5 mehrfach neu erfunden. Weshalb gerade einige Entwickler irgendwann aufgehört haben weiter zu gehen. Da muss wieder eine gewisse Verlässlichkeit und Stabilität rein. Man will auch mal seine eigene Anwendung weiter entwickeln und sich nicht nur mit dem Anpassen an die nächste Qt Version beschäftigen.
Naja, so oft gibts aber keinen neuen Qt Major Release.
Und Qt4 auf Qt5 ist auch für den meisten Code ziemlich trivial.
Oft benutzen Anwendungsentwickler halt die Umstellung auch aus, um selbst Neuerungen oder Umbauten vor zu nehmen, aber ist dann schon deren Entscheidung.
Viele Anwendungen bei KDE haben zum Beispiel in der Qt3 nach Qt4 Transition zuerst mal nur Änderungen gemacht, die durch Qt4 notwendig wurden und erst im Laufe ihrer 4er Serie Internas umgebaut.
Zusätzlich müssen Anwendungsentwickler ja auch nicht zu erstmöglichen Zeitpunkt wechseln, die Bibliotheken sind schließlich parallel installiertbar.
Ich habe hier zum Beispiel Qt4 basiertes Okular und Qt5 basiertes Gwenview.
Der größte Teil der "paar hundert MB" ist die Chromium Engine, aka QtWebEngine. Hier kannst Du jede Menge redundanten Code einsparen, wenn Du beim Bauen gegen die System-Libs linkst, und nicht gegen die Kopien des Chromium-Projekts. So lässt sich zB. QtWebEngine gegen die System-ffmpeg linken.
Google sollte einfach aufhören, externe Libs zu patchen und dann in Chromium aufzunehmen...
Einen Vorteil hat die Qt-Chromium-Integration: noch nie war es so einfach, einen vollständigen, modernen Browser (HTML5, WebRTC, etc...) mit ein paar Zeilen C++-Code (oder sogar QML) zu bauen
Wir haben eine 100000 Zeilen Sourcecode Software in Qt4 geschrieben und in 5 Tagen auf Qt 5.x umgestellt. Die Entscheidung für Qt vor 5 Jahren war genau richtig. Die meisten neuen Toolkits sind für unsere Desktop Software uninteressant. Wichtig sind uns Bugfixes und Stabilität um möglichst wenig Workarounds zu bauen.
Angesichts des KDE4-Debakels war ich mal auf reine Qt-Anwendungen umgeschwenkt und somit Qt-Fan.
Aber das war wohl der Sprung vom Regen in die Traufe. Irgendwelches marodes QtWebKit-Zeugs aus Qt-4.xx ist immer noch Grundlage von alternativen Browsern wie Netsurf oder Midori, und welche Bomben im nicht mehr gewarteten Qt 4.xx noch schlummern, weiss keiner.
Und wenn ich mir Qt 5.6 selbst kompiliere (bin Slackware-User), lade ich mir ein paar hundert (vermutlich unwartbare) MB Sourcen runter, die nach stundenlangem kompilieren in einem 50 MB grossen Blob landen.
Aber ist ja egal, der Kram wird in 2 oder 3 Jahren ohnehin weggeschmissen und durch ein paar GB Sourcen ersetzt, durch die erst recht keiner mehr durchblickt.
Auf Heise kann man täglich lesen, wie das Zeug den Leuten um die Ohren fliegt, aber es wird unentwegt auf den alten Müll immer mehr neuer Müll aufgetürmt. Und da es für die Smartphone-addicted-Kids nicht bunt und hip genug sein kann, geht es immer so weiter.
Ich werde wohl langsam zu alt für den Scheiss.
Es gibt Toolkits die sich schneller entwickeln und welche die sich langsamer entwickeln.
Die schneller entwickelnden Toolkits wie Qt und GTK+ werden schnell durch eine inkompatible neue Version ersetzt. Diese bietet aber mehr Features.
Toolkits wie das Fox Toolkit und FLTK werden ebenfalls kontinuerlich weiterentwickelt. Aber dort geht die Entwicklung langsamer voran. Dort kannst Du sicher noch immer 10 Jahre alten Quellcode gegen die aktuelle Version den Toolkits kompilieren. Aber dort gibt es auch kaum Neuerungen.
Und mit der fortschreitenden Entwicklung geschieht es automatisch, daß man merkt, daß es besser wäre einige grundlegende Dinge des Toolkits umzustrukturieren. Dadurch wird es zwar inkompatibel zu älteren Versionen, unterstützt dann aber auch neuere C++-Features.
Die Entwicklung wie sie sich entwickeln, ist bei allen Toolkits recht ähnlich. Nur die Geschwindigkeit in der es geschieht ist eine andere.
Dann nimm für Deine eigenen Projekte entweder ein Toolkit, das sich nur langsam entwickelt oder verwende das aktuelle Qt und bleib auch die kommenden Jahre bei der Version.Es gibt da große Probleme, die nicht in der Hand der Qt Entwickler liegen,
sondern von Apple und Google verursacht worden sind.
Und zwar der Fork von WebKit (dem ursprünglichen KHTML) in Blink.
Früher (Qt 4.8) gab es sogar mal ein QWebKit für Android (von Bogdan Vatra). Heute gibt es auf Smatphones weder QWebKit noch Blink (QWebEngine) sondern nur noch QML Kram und das rudimentäre QTextBrowser.
Ich persönlich habe mich dazu entschieden nur den Widget orientierten Teil von Qt zu verwenden.
Bei der Netzwerkkommunikation setze ich dierekt auf der Socket Bibliothek (Transportschicht) auf.
Graphische Experimente sind mittels SVG aber schön mit Qt zu realisieren. Leider fehlt dort inzwischen der WebKit basierte SVG Renderer und man muß bei QSvgRenderer bleiben.
Grundsätzlich habe ich die Erfahrung gemacht, dass man sich so wenig wie möglich auf fremde Bibliotheken stützen sollte. Es ist häufig sinnvoll sich auf die Verwendung der Posix Funktionen zu beschränken bzw. direkt auf Standard-Formaten bzw. Standard-Protokollen aufzusetzen.
Wichtiger als die Entwicklungsgeschwindigkeit eines Toolkits / Frameworks ist die Stabilität dessen Schnittstellen. Qt und speziell KDE hat sich nach KDE 4.5 mehrfach neu erfunden. Weshalb gerade einige Entwickler irgendwann aufgehört haben weiter zu gehen. Da muss wieder eine gewisse Verlässlichkeit und Stabilität rein. Man will auch mal seine eigene Anwendung weiter entwickeln und sich nicht nur mit dem Anpassen an die nächste Qt Version beschäftigen.
Naja, so oft gibts aber keinen neuen Qt Major Release.
Und Qt4 auf Qt5 ist auch für den meisten Code ziemlich trivial.
Oft benutzen Anwendungsentwickler halt die Umstellung auch aus, um selbst Neuerungen oder Umbauten vor zu nehmen, aber ist dann schon deren Entscheidung.
Viele Anwendungen bei KDE haben zum Beispiel in der Qt3 nach Qt4 Transition zuerst mal nur Änderungen gemacht, die durch Qt4 notwendig wurden und erst im Laufe ihrer 4er Serie Internas umgebaut.
Zusätzlich müssen Anwendungsentwickler ja auch nicht zu erstmöglichen Zeitpunkt wechseln, die Bibliotheken sind schließlich parallel installiertbar.
Ich habe hier zum Beispiel Qt4 basiertes Okular und Qt5 basiertes Gwenview.
Der größte Teil der "paar hundert MB" ist die Chromium Engine, aka QtWebEngine.
Hier kannst Du jede Menge redundanten Code einsparen, wenn Du beim Bauen gegen die System-Libs linkst, und nicht gegen die Kopien des Chromium-Projekts.
So lässt sich zB. QtWebEngine gegen die System-ffmpeg linken.
Google sollte einfach aufhören, externe Libs zu patchen und dann in Chromium aufzunehmen...
Einen Vorteil hat die Qt-Chromium-Integration: noch nie war es so einfach, einen vollständigen, modernen Browser (HTML5, WebRTC, etc...) mit ein paar Zeilen C++-Code (oder sogar QML) zu bauen
Außerdem sind weder QtWebKit noch QtWebEngine so zentral wichtige Module, dass jede Qt Applikation davon Gebrauch machen müsste.
Von den Hauptmodulen ist QtWidgets mit 6,6 MB schon das Größte in meinem /usr/lib
Wir haben eine 100000 Zeilen Sourcecode Software in Qt4 geschrieben und in 5 Tagen auf Qt 5.x umgestellt. Die Entscheidung für Qt vor 5 Jahren war genau richtig. Die meisten neuen Toolkits sind für unsere Desktop Software uninteressant. Wichtig sind uns Bugfixes und Stabilität um möglichst wenig Workarounds zu bauen.