Qt/Quick und Qt/Widgets sind derzeit inkompatible Lösungen und die kontroverse Diskussion welcher Pfad sich durchsetzt ist bisher nur ansatzweise beim Anwender angekommen.
Ich denke nicht, dass das in irgendeiner weise beim Benutzer ankommen wird. Die "kontroverse Diskussion" wird künstlich von Leuten vom Zaun gebrochen, die aus welchen Gründen auch immer keine weitere Option für UI haben wollen.
Für die meisten Qt verwendenden Entwickler ist das völlig egal, man benutzt jeweils das für den eigenen Bedarf besser zugeschnittene Modul.
Ob das dann QtWidgets oder QtQuick ist bleibt damit die Entscheidung des Programmherstellers, der wiederum die Bedürfnisse seiner Kunden berücksichtigen wird.
Eine Option war Qt/Quick 1, aber mit Qt5 ist das halt nicht so einfach, weil Du dort Widgets und QML/Komponenten nur bedingt mischen kannst. D.h. Du mußt Dich grundsätzlich festlegen auch wenn Du für unterschiedliche Elemente Deiner Oberfläche zu verschiedenen Ergebnissen kommen würdest ( hoffentlich ändert sich das mit Qt 5.1. ).
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. Am Ende bedeutet sie vermutlich den Stillstand jeglicher Eigenentwicklung weil man auf lange Zeit damit beschäftigt ist den Status Quo irgendwie auf Qt/Quick zu duplizieren.
Wenn man dagegen die Dualität in der Bibliothek nicht nachvollziehen will, trifft man die Entscheidung - aufgrund der derzeitigen Unverträglichkeiten - für die Anwender mit, ohne die Anwendung und die Präferenzen der beteiligten Entwickler überhaupt zu kennen.
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.
Ich denke nicht, dass das in irgendeiner weise beim Benutzer ankommen wird.
Die "kontroverse Diskussion" wird künstlich von Leuten vom Zaun gebrochen, die aus welchen Gründen auch immer keine weitere Option für UI haben wollen.
Für die meisten Qt verwendenden Entwickler ist das völlig egal, man benutzt jeweils das für den eigenen Bedarf besser zugeschnittene Modul.
Ob das dann QtWidgets oder QtQuick ist bleibt damit die Entscheidung des Programmherstellers, der wiederum die Bedürfnisse seiner Kunden berücksichtigen wird.
Eine Option war Qt/Quick 1, aber mit Qt5 ist das halt nicht so einfach, weil Du dort Widgets und QML/Komponenten nur bedingt mischen kannst. D.h. Du mußt Dich grundsätzlich festlegen auch wenn Du für unterschiedliche Elemente Deiner Oberfläche zu verschiedenen Ergebnissen kommen würdest ( hoffentlich ändert sich das mit Qt 5.1. ).
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. Am Ende bedeutet sie vermutlich den Stillstand jeglicher Eigenentwicklung weil man auf lange Zeit damit beschäftigt ist den Status Quo irgendwie auf Qt/Quick zu duplizieren.
Wenn man dagegen die Dualität in der Bibliothek nicht nachvollziehen will, trifft man die Entscheidung - aufgrund der derzeitigen Unverträglichkeiten - für die Anwender mit, ohne die Anwendung und die Präferenzen der beteiligten Entwickler überhaupt zu kennen.
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.