Was allgemein übersehen wurde ist die Situation der Qt Addon Bibliotheken deren Entwickler vor dem Problem stehen auf die Dualität reagieren zu müssen.
Da sehe ich eigentlich kein Problem. Abhängig von der Art des Addons ist es entweder ein Addon zu QtCore, QtWidgets, QtQuick etc.
Ein vorhandenes Widget Addon bleibt ja weiter einsetzbar, das einzige was sich ändert ist, dass eventuell sogar die Möglicheit besteht, Verbesserungen direkt in Qt aufgenommen zu bekommen.
Beide Ansätze (also widget addon und Einpflegen von Verbesserungen direkt in Qt) werden von Leute gemacht, die an KDE Frameworks arbeiten (das dann auch noch Addons zu anderen Qt Modulen bringen wird).
Ich würde davon ausgehen, dass die engagierten Addon Entwickler dem Beispiel von KDE folgen werden und das Resultat noch flexibler einsetzbare Komponenten sein werden.
Die üblichen Qt Addon Bibliotheken sind Qxt und Qwt - die Situation für KDE ist da weniger schwierig, da die Anzahl der KDE Anwendungen überschaubar ist und ein direkter Kontakt zwischen Anwendungs und Bibliotheksentwicklern besteht. Gerade im kommerziellen Umfeld und auf anderen Betriebssystemen ist die Verwendung der KDE Bibliotheken auch nicht wirklich verbreitet.
Um z.B. das Qwt Plot Framework auch Qt/Quick Anwendungen zur Verfügung stellen zu können, muß man den Code erheblich umbauen um ihn Scene Graph kompatibel zu machen. Das geht nicht ohne massive API Änderungen, die dann zu verständlichem Unmut auf Anwenderseite führt - insbesondere bei denen die Qt/Widgets weiter verwenden wollen ( = nahezu alle, da wohl niemand bestehende Applikationen ohne Not auf Qt/Quick umschreibt ).
Klar man kann auch sagen, dass man Qt/Quick einfach ignoriert - aber damit nimmt man allen Anwendungen die Wahlmöglichkeit - z.B. auch allen KDE Anwendungen die Qwt zum Plotten verwenden.
Was ich meinte ist, dass Qt4 Bibiotheken oder Addons nach wie vor so einsetzbar bleiben, wie sie es unter Qt4 sind, dass aber zusätzlich durch die bessere Modularisierung von Qt5 eben auch Zusatzbibliotheken durchaus in einem breiterem Rahmen verfügbar gemacht werden könnten.
Als Beispiel eben die entsprechenden Umgliederung des KDE Framework 5 Projektes, wo Bibliotheken, die im wesentlichen Addons zu verschiedenen Qt Modulen sind, als solche allein gestellt nutzbar gemacht werden.
Klar man kann auch sagen, dass man Qt/Quick einfach ignoriert - aber damit nimmt man allen Anwendungen die Wahlmöglichkeit - z.B. auch allen KDE Anwendungen die Qwt zum Plotten verwenden.
Das sehe ich weniger problematisch. Benutzer von Qwt werden das weiter verwenden können und werden im Normalfall auch nicht ihre Applikation neu umschreiben (u.a. weil für Anwendungen mit Qwt Benutzung vermutlich Widgetbasierte UI einfach passender ist).
Zusätzlich besteht ja auch in QtQuick 2 die Möglichkeit weiter Teile der UI mit QPainter zu erzeugen, bzw in QtWidgets mit OpenGL zu arbeiten.
Da sehe ich eigentlich kein Problem. Abhängig von der Art des Addons ist es entweder ein Addon zu QtCore, QtWidgets, QtQuick etc.
Ein vorhandenes Widget Addon bleibt ja weiter einsetzbar, das einzige was sich ändert ist, dass eventuell sogar die Möglicheit besteht, Verbesserungen direkt in Qt aufgenommen zu bekommen.
Beide Ansätze (also widget addon und Einpflegen von Verbesserungen direkt in Qt) werden von Leute gemacht, die an KDE Frameworks arbeiten (das dann auch noch Addons zu anderen Qt Modulen bringen wird).
Ich würde davon ausgehen, dass die engagierten Addon Entwickler dem Beispiel von KDE folgen werden und das Resultat noch flexibler einsetzbare Komponenten sein werden.
Die üblichen Qt Addon Bibliotheken sind Qxt und Qwt - die Situation für KDE ist da weniger schwierig, da die Anzahl der KDE Anwendungen überschaubar ist und ein direkter Kontakt zwischen Anwendungs und Bibliotheksentwicklern besteht. Gerade im kommerziellen Umfeld und auf anderen Betriebssystemen ist die Verwendung der KDE Bibliotheken auch nicht wirklich verbreitet.
Um z.B. das Qwt Plot Framework auch Qt/Quick Anwendungen zur Verfügung stellen zu können, muß man den Code erheblich umbauen um ihn Scene Graph kompatibel zu machen. Das geht nicht ohne massive API Änderungen, die dann zu verständlichem Unmut auf Anwenderseite führt - insbesondere bei denen die Qt/Widgets weiter verwenden wollen ( = nahezu alle, da wohl niemand bestehende Applikationen ohne Not auf Qt/Quick umschreibt ).
Klar man kann auch sagen, dass man Qt/Quick einfach ignoriert - aber damit nimmt man allen Anwendungen die Wahlmöglichkeit - z.B. auch allen KDE Anwendungen die Qwt zum Plotten verwenden.
Was ich meinte ist, dass Qt4 Bibiotheken oder Addons nach wie vor so einsetzbar bleiben, wie sie es unter Qt4 sind, dass aber zusätzlich durch die bessere Modularisierung von Qt5 eben auch Zusatzbibliotheken durchaus in einem breiterem Rahmen verfügbar gemacht werden könnten.
Als Beispiel eben die entsprechenden Umgliederung des KDE Framework 5 Projektes, wo Bibliotheken, die im wesentlichen Addons zu verschiedenen Qt Modulen sind, als solche allein gestellt nutzbar gemacht werden.
Das sehe ich weniger problematisch. Benutzer von Qwt werden das weiter verwenden können und werden im Normalfall auch nicht ihre Applikation neu umschreiben (u.a. weil für Anwendungen mit Qwt Benutzung vermutlich Widgetbasierte UI einfach passender ist).
Zusätzlich besteht ja auch in QtQuick 2 die Möglichkeit weiter Teile der UI mit QPainter zu erzeugen, bzw in QtWidgets mit OpenGL zu arbeiten.