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.
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.