...A big new thing we aim to release during 2018 is Qt for Python, i.e. bindings to Python programming language
Das verstehe ich nicht. Mit der GNU GPL v3 Bibliothek PyQt (aktuell derzeit PyQt5.10) von Riverbank funktioniert das schon seit Jahren prima. Was ist daran "new" oder "big"?
Qt stammt von einer kommerziellen Softwarebude. Die fragen sich nicht: "Gibt es da schon was?", sondern die fragen sich: "Womit können wir unsere Einnahmen sichern bzw, vergrößern?"
Darum muss da ständig was neues drangetackert werden, egal, ob es sinnvoll ist oder nicht. Hauptsache, die zahlende Kundschaft bleibt bei Laune und zahlt.
Und die nichtzahlende Kundschaft muss halt damit leben, dass der Blob fetter und fetter wird.
Vermutlich ist das eher die Ankündigung, PySide offiziell zu veröffentlichen und zu unterstützen.
PyQt ist natürlich derzeit die am häufigsten benutzte Python Binding für Qt, aber für proprietäre Software nur durch eine zusätzliche Lizenz verfügbar.
Wo im Blog-Post steht denn, dass QtQuick der derzeitig empfohlene Weg für zweidimensionale Oberflächen ist? Ich kann nur die Aussage finden, dass in vielen Fällen QtQuick ausreichend ist, aber weiterhin sowohl QtQuick als auch QtWidgets voll unterstützt werden und ihre eigenen Anwendungsbereiche haben.
Aus eigener Erfahrung kann ich sagen, dass QtQuick mit QtQuickControls derzeit nur für einfache Desktop-Anwendungen geeignet ist, es fehlen einfach noch zu viele Funktionen.
Das Quick Controls 1 Modul - also der QML Pfad für den Desktop - wird laut Entwickler Liste bald in Deprecated Modus gehen. D.h. für klassische Desktop Anwendungen ist das schon heute ein totes Pferd. Letztendlich war das aber ohnehin schon lange absehbar - sonst hätte die Entwicklung ja nicht noch mal von Vorne angefangen.
Was aber macht Quick Controls 2 nun anders, damit das ganze nicht wieder so fett wird ?
Im wesentlichen fallen mir da 2 Punkte auf:
- Fallenlassen von Features ( in der Regel Desktop Sachen ) - Implementierung zum großen Teil in C++
Der 2. Punkt ist in dem Zusammenhang natürlich bemerkenswert, weil er unmittelbar die Frage aufwirft warum eine Technologie für Anwendungscode gut sein soll, wenn man sie als grundsätzliches Problem bei der Implementierung des Moduls identifiziert hat.
Was aber macht Quick Controls 2 nun anders, damit das ganze nicht wieder so fett wird ?
Im Wesentlichen eine Konzentration auf die grundsätzlichen Anwendungsfälle in den Komponenten selbst, bzw. verschiedene Komponenten für versciiedene Einsatzfälle anstatt "eierlegende Wollmilchsäue"
Dann noch eine bessere Trennung zwischen der Logik der Komponnenten und ihrer Visualisierung, damit man bei der Anpassung von Letzterem weniger "kopieren" muss.
Erwähnenswert bei QtWebEngine ist vielleicht, dass sie unter Windows nur mit VisualStudio-Compilern rennt; mit mingw ist da Schicht im Schacht.
Ich hätte mir gewünscht, dass das eigentlich schon ausreichend Manko ist, um diesen Weg garnicht erst zu bestreiten, sondern es lieber doch irgendwie anders zu lösen.
Erwähnenswert bei QtWebEngine ist vielleicht, dass sie unter Windows nur mit VisualStudio-Compilern rennt
Siehe; https://doc.qt.io/qt-5.10/qtwebengine-platform-notes.html Oder meintest du im Artikel?
Ich hätte mir gewünscht, dass das eigentlich schon ausreichend Manko ist, um diesen Weg garnicht erst zu bestreiten, sondern es lieber doch irgendwie anders zu lösen.
Wie denn? Einen eigenen Browser schreiben? (Wahnsinn ...) Oder mit WebKit weit abgeschlagen bleiben?
Cool wäre zwar eine moderne Lösung ohne Chromium, aber das wird wohl so schnell nix 
Ich habe es oben schon geschrieben, wie stellt ihr euch das vor? Ein Browser hat die Komplexität eines ausgewachsenen Betriebssystem. Sie (Qt) hatte die Wahl zwischen WebKit (veraltet / löchrig und der federführende Apple hat kein Interesse das zu ändern), Blink (also die QtWebEngine) oder Gecko (war damals zu langsam).
Stimmt und deshalb nutzt Apple Webkit weil die kein Interesse haben und lieber löchrige Software verwenden? Dein Pfleger sollte deinen Internetzugang besser reglementieren.
Von Wasserrasierer am So, 25. Februar 2018 um 23:49 #
>Und selber schreiben? Faktisch unmöglich. Einfach weglassen und jeglichen Webdreck am ausgestreckten Arm verhungern lassen. Nochn bisschen mit dem Finger auf die wochentliche npm/Electron-Lücke zeigen und sicherstellen, dass überhaupt niemand auf die abstruse Idee kommt, irgendwas in die Richtung betreiben zu wollen.
Jaja, für the Qt Company mit "Kundenorientierung" und Login-Gängelung beim Download der FOSS-Version undenkbar. Kein gutes Zeichen, dass die sich das erlauben, während der andere Krempel technisch ganz vor die Hunde geht.
Witzig. Bei den Hardware-Uhren hat man sich einbauseitig immer viel Mühe gemacht, damit diese nicht spiegeln. Nun macht man die Spiegelung per Software rein...
Von HansiHinterseher am Mo, 26. Februar 2018 um 13:14 #
Hat jemand Erfahrung zu Qt bzw. Qt Quick unter Android? Wie ist da das Look & Feel der GUI? Es werden ja sicherlich nicht die nativen Android-Widget benutzt?
Wie weit sehen die Qt-Varianten unter Android aus und wie verhalten diese sich? Merkt der User direkt etwas oder nur an wenigen Unterschiede?
Vielleicht offizielle, von Qt stammende, bindings? Die auch nicht GPL sondern LGPL sind.
Qt stammt von einer kommerziellen Softwarebude. Die fragen sich nicht: "Gibt es da schon was?", sondern die fragen sich: "Womit können wir unsere Einnahmen sichern bzw, vergrößern?"
Darum muss da ständig was neues drangetackert werden, egal, ob es sinnvoll ist oder nicht. Hauptsache, die zahlende Kundschaft bleibt bei Laune und zahlt.
Und die nichtzahlende Kundschaft muss halt damit leben, dass der Blob fetter und fetter wird.
Du verstehst nicht wirklich was davon, gell?
QT war die letzten 15 Jahre nicht so schlank und modular wie heute du Dummbratzen - Das genaue Gegenteil von BLOB
Vermutlich ist das eher die Ankündigung, PySide offiziell zu veröffentlichen und zu unterstützen.
PyQt ist natürlich derzeit die am häufigsten benutzte Python Binding für Qt, aber für proprietäre Software nur durch eine zusätzliche Lizenz verfügbar.
Wo im Blog-Post steht denn, dass QtQuick der derzeitig empfohlene Weg für zweidimensionale Oberflächen ist? Ich kann nur die Aussage finden, dass in vielen Fällen QtQuick ausreichend ist, aber weiterhin sowohl QtQuick als auch QtWidgets voll unterstützt werden und ihre eigenen Anwendungsbereiche haben.
Aus eigener Erfahrung kann ich sagen, dass QtQuick mit QtQuickControls derzeit nur für einfache Desktop-Anwendungen geeignet ist, es fehlen einfach noch zu viele Funktionen.
Das Quick Controls 1 Modul - also der QML Pfad für den Desktop - wird laut Entwickler Liste bald in Deprecated Modus gehen. D.h. für klassische Desktop Anwendungen ist das schon heute ein totes Pferd. Letztendlich war das aber ohnehin schon lange absehbar - sonst hätte die Entwicklung ja nicht noch mal von Vorne angefangen.
Was aber macht Quick Controls 2 nun anders, damit das ganze nicht wieder so fett wird ?
Im wesentlichen fallen mir da 2 Punkte auf:
- Fallenlassen von Features ( in der Regel Desktop Sachen )
- Implementierung zum großen Teil in C++
Der 2. Punkt ist in dem Zusammenhang natürlich bemerkenswert, weil er unmittelbar die Frage aufwirft warum eine Technologie für Anwendungscode gut sein soll, wenn man sie als grundsätzliches Problem bei der Implementierung des Moduls identifiziert hat.
Im Wesentlichen eine Konzentration auf die grundsätzlichen Anwendungsfälle in den Komponenten selbst, bzw. verschiedene Komponenten für versciiedene Einsatzfälle anstatt "eierlegende Wollmilchsäue"
Dann noch eine bessere Trennung zwischen der Logik der Komponnenten und ihrer Visualisierung, damit man bei der Anpassung von Letzterem weniger "kopieren" muss.
Erwähnenswert bei QtWebEngine ist vielleicht, dass sie unter Windows nur mit VisualStudio-Compilern rennt; mit mingw ist da Schicht im Schacht.
Ich hätte mir gewünscht, dass das eigentlich schon ausreichend Manko ist, um diesen Weg garnicht erst zu bestreiten, sondern es lieber doch irgendwie anders zu lösen.
https://doc.qt.io/qt-5.10/qtwebengine-platform-notes.html
Oder meintest du im Artikel? Wie denn?
Einen eigenen Browser schreiben? (Wahnsinn ...)
Oder mit WebKit weit abgeschlagen bleiben?
> Neuerungen für Qt 5.12
> Qt WebEngine von der Veröffentlichung von Qt abzukoppeln
Yes!
Cool wäre zwar eine moderne Lösung ohne Chromium, aber das wird wohl so schnell nix
Sie (Qt) hatte die Wahl zwischen WebKit (veraltet / löchrig und der federführende Apple hat kein Interesse das zu ändern), Blink (also die QtWebEngine) oder Gecko (war damals zu langsam).
Und selber schreiben? Faktisch unmöglich.
Stimmt und deshalb nutzt Apple Webkit weil die kein Interesse haben und lieber löchrige Software verwenden?
Dein Pfleger sollte deinen Internetzugang besser reglementieren.
Jaja Apple ist ja auch so toll was Sicherheit betrifft - Wach mal auf
>Und selber schreiben? Faktisch unmöglich.
Einfach weglassen und jeglichen Webdreck am ausgestreckten Arm verhungern lassen. Nochn bisschen mit dem Finger auf die wochentliche npm/Electron-Lücke zeigen und sicherstellen, dass überhaupt niemand auf die abstruse Idee kommt, irgendwas in die Richtung betreiben zu wollen.
Jaja, für the Qt Company mit "Kundenorientierung" und Login-Gängelung beim Download der FOSS-Version undenkbar. Kein gutes Zeichen, dass die sich das erlauben, während der andere Krempel technisch ganz vor die Hunde geht.
> sicherheitskritische Bedienoberflächen
Amaturenbrett
Gibt’s schon etwas länger:
https://commons.wikimedia.org/wiki/File:Porsche_218_Amaturenbrett.JPG
Witzig. Bei den Hardware-Uhren hat man sich einbauseitig immer viel Mühe gemacht, damit diese nicht spiegeln.
Nun macht man die Spiegelung per Software rein...
Hat jemand Erfahrung zu Qt bzw. Qt Quick unter Android? Wie ist da das Look & Feel der GUI? Es werden ja sicherlich nicht die nativen Android-Widget benutzt?
Wie weit sehen die Qt-Varianten unter Android aus und wie verhalten diese sich? Merkt der User direkt etwas oder nur an wenigen Unterschiede?