Von Josef Hahn am Fr, 13. Dezember 2019 um 13:05 #
Irgendwie hängt man an Google. Wenn man auch für Windows bauen will, hängt man auch an VS. Mingw?! Nöööö.... Das unterstützt Google ja nicht.......
Als Bonus darf man sich dann noch daran erfreuen, dass das Mistding sich nichtmal an Qt Styling hält. Überall in meine System erkenne ich die Verwendung dieser Engine direkt daran, dass sie nicht die Scrollbars (und Buttons, ...) hat, die ich überall anders habe, sondern irgendwas "gaaanz ungefähr so wie Win 10"-mäßiges...
Naja, schade, geht ja scheinbar derzeit nicht besser...
Von DarkKnight am So, 15. Dezember 2019 um 12:28 #
Es ist von den Programmierer durchdacht, Qt künftig unabhängig von der vom Betriebssystem bereitgestellten 3D-Grafik-API zu machen. Bisher wurde sich nämlich nur auf OpenGL als Basis-Grafik-API konzentriert. Mit Qt 5.14 soll begonnen werden eine grössere Anzahl an etlichen verschiedenen Grafik-ALIs zu unterstützen. Qt 5.14 enthält somit eine erste Vorschau eines grafik-API-unabhängigen Szenegraphen-Renderers als Opt-in-Funktion, mit der Qt Quick-Anwendungen auf Vulkan, Metall, Direct3D 11 wie auch künftige Programmierschnittstellen ausgeführt werden können. Das ist sicherlich eine Erleichterung, die Qt-Anwendungen individuell und direkt über die vom Betriebssystem bereitgestellt native Grafik-API auszuführen, zumal dies sicherlich auch das Upgrade auf Qt6 erleichtert, da die Rendering Hardware Schnittstelle die Standardmethode für das Rendern von Grafiken in Qt 6 sein wird.
Die Qt Company hat vor Kurzem die allgemeine Verfügbarkeit von Qt for MCUs verkündet. Das Toolkit ist auf die Embedded-Entwicklung ausgelegt. Entwickler können damit Qt-Anwendungen für Mikroprozessoren wahlweise über ein Echtzeitbetriebssystem (Real-time Operating System, RTOS) oder im Bare-Metal-Betrieb ohne Betriebssystem erstellen.
Naja im Wesentlichen ist das eine Version in der man QML kastriert, weil die Technologie zu viele Resourcen für solche Plattformen frisst. Das ist auch in etwa der Ansatz der hinter QML3 ( Qt6 ) steht - auch da geht es darum die schlechte Bilanz durch Vereinfachung der Sprache ( z.B. kein JavaScript mehr ) zu verbessern.
Wenn man noch berücksichtigt, dass im Qt5 Zyklus die in QML implementierten Controls durch neue Controls ersetzt worden sind, die im wesentlichen in C++ geschrieben sind ( Qt/Quick Controls 2 ), darf man da wohl zurecht schlussfolgern, dass man mit QML - als Technologie für Embedded - derzeit noch nicht wirklich optimal bedient ist.
Das was da als Riesen-Innovation verkauft wird ist eher ein schrittweises Zurückrudern bis man endlich einen hoffentlich sinnvollen Kompromiss zwischen deklarativer Programmierung und sinnvollem Ressourcenverbrauch gefunden hat.
Irgendwie hängt man an Google. Wenn man auch für Windows bauen will, hängt man auch an VS. Mingw?! Nöööö.... Das unterstützt Google ja nicht.......
Als Bonus darf man sich dann noch daran erfreuen, dass das Mistding sich nichtmal an Qt Styling hält. Überall in meine System erkenne ich die Verwendung dieser Engine direkt daran, dass sie nicht die Scrollbars (und Buttons, ...) hat, die ich überall anders habe, sondern irgendwas "gaaanz ungefähr so wie Win 10"-mäßiges...
Naja, schade, geht ja scheinbar derzeit nicht besser...
Wenn es eine bessere Alternative gibt mit der man alle Funktionen in QT ersetzen, gibt nochmal gescheit....
Quicktime ist nie gescheit
Es ist von den Programmierer durchdacht, Qt künftig unabhängig von der vom Betriebssystem bereitgestellten 3D-Grafik-API zu machen.
Bisher wurde sich nämlich nur auf OpenGL als Basis-Grafik-API konzentriert. Mit Qt 5.14 soll begonnen werden eine grössere Anzahl an etlichen verschiedenen Grafik-ALIs zu unterstützen.
Qt 5.14 enthält somit eine erste Vorschau eines grafik-API-unabhängigen Szenegraphen-Renderers als Opt-in-Funktion, mit der Qt Quick-Anwendungen auf Vulkan, Metall, Direct3D 11 wie auch künftige Programmierschnittstellen ausgeführt werden können.
Das ist sicherlich eine Erleichterung, die Qt-Anwendungen individuell und direkt über die vom Betriebssystem bereitgestellt native Grafik-API auszuführen, zumal dies sicherlich auch das Upgrade auf Qt6 erleichtert, da die Rendering Hardware Schnittstelle die Standardmethode für das Rendern von Grafiken in Qt 6 sein wird.
Die Qt Company hat vor Kurzem die allgemeine Verfügbarkeit von Qt for MCUs verkündet. Das Toolkit ist auf die Embedded-Entwicklung ausgelegt. Entwickler können damit Qt-Anwendungen für Mikroprozessoren wahlweise über ein Echtzeitbetriebssystem (Real-time Operating System, RTOS) oder im Bare-Metal-Betrieb ohne Betriebssystem erstellen.
Naja im Wesentlichen ist das eine Version in der man QML kastriert, weil die Technologie zu viele Resourcen für solche Plattformen frisst. Das ist auch in etwa der Ansatz der hinter QML3 ( Qt6 ) steht - auch da geht es darum die schlechte Bilanz durch Vereinfachung der Sprache ( z.B. kein JavaScript mehr ) zu verbessern.
Wenn man noch berücksichtigt, dass im Qt5 Zyklus die in QML implementierten Controls durch neue Controls ersetzt worden sind, die im wesentlichen in C++ geschrieben sind ( Qt/Quick Controls 2 ), darf man da wohl zurecht schlussfolgern, dass man mit QML - als Technologie für Embedded - derzeit noch nicht wirklich optimal bedient ist.
Das was da als Riesen-Innovation verkauft wird ist eher ein schrittweises Zurückrudern bis man endlich einen hoffentlich sinnvollen Kompromiss zwischen deklarativer Programmierung und sinnvollem Ressourcenverbrauch gefunden hat.