Qt 6 Will Bring Improvements To The Toolkit's Python Support

[carewolf]

It's very shameful, really. That was my suspicion, now confirmed. It's the evil of corporatism, it seems...

Don't bother with out resident Qt troll. He always pops up into Qt threads and spouts nonsense.

[FireBurn]

No; PyQT is a project by Riverbank Computing, whereas Qt for Python is the new name for the old PySide project now that it's been officially endorsed by the QT company. The reason that there's two projects is that the older PyQT project is only GPLv3/Commercial, whereas the newer PySide/Qt for Python bindings are GPLv3/LGPLv3/Commercial i.e. the licensing is a bit easier.

Thanks for explaining

[miabrahams]

3. One of the main reasons why I spent a big chunk of my life learning C/C++ (and subsequently Qt) was because I wanted to write the fastest, tightest, most efficient code possible while still being portable. Forcing me to dump an entire Javascript interpreter into my app just to display "Hello World" really rubs me the wrong way, especially when I'm told it's the only recommended approach for Android. All of my Android devices are highly memory, CPU, and battery limited, this is such insane/backwards advice! Qt Widgets is fast and lightweight.

Moving forward, I seem to be doing more and more of my work in OpenGL, since it is even faster/more reliable than Qt Widgets and seems to be pretty portable. Eventually, if I keep moving that way and Qt keeps moving away from Qt Widgets in favor of VM/interpreter languages, I might just drop Qt entirely and switch to SDL.

The main benefit of Qt Quick / QML is that it can be efficiently drawn by a GPU. Qt6 will be making the Javascript runtime optional and provide functionality to compile QML to C++.

[Kernelcoffee]

Problems with QML/Qt Quick Controls 2:
I don't like javascript

FTFY

it's the only recommended approach for Android

Java/Kotlin with the official Android SDK and the Native DevKit are sad.

tl;tw: QtWidget is not optimal for Android or touchscreen systems in general because it's not made for that, Qml/QtQuick is, that's why it's the only recommended Qt approach.

[ed31337]

The main benefit of Qt Quick / QML is that it can be efficiently drawn by a GPU. Qt6 will be making the Javascript runtime optional and provide functionality to compile QML to C++.

Sounds like a potentially good step in the right direction. Frankly, I'd like to avoid QML entirely if possible. If Qt would let you use all the Qt Quick Controls 2 straight from C++ and really let you get inside to tweak things, that would be really good. Qt Widgets is great because even if the pre-canned Qt Widgets code doesn't do what I want, it's easy enough to extend a Qt Widgets class in C++ to create customized versions of widgets that implement the exact behavior that I want, in an easily re-usable format for all my projects.

In QML, if the pre-canned solution doesn't do what I want or has bugs, I'm pretty much at a loss as to how I can fix it. Maybe I can write a pile of Javascript to work around the problem, but that irks me because I really don't want big piles of Javascript code in my app. I can't really write a lot of C++ to fix such problems either because using QML means all the GUI code is running inside a separate thread owned by the Javascript interpreter. It's so awkward to do QML GUI repairs from C++ since I'm in the wrong thread.

[ed31337]

I don't like javascript
FTFY

Yes. I don't exactly like Javascript. The idea of being able to modify code at run-time without compiling is great for rapid initial development, but why not be 100% compatible with C++ and compilable to native code so that I can later get all the speed, efficiency, and extensibility benefits once initial development has solidified? Javascript kind of falls just a tad short of that ideal. Maybe Qt 6's QML compiled to C++ feature will solve it and make everything wonderful? Here's to hoping!

I really don't like Java/Kotlin, far more so than my slight dislike of Javascript. Anybody remember back when Java was touted as the "write-once, run-anywhere" solution to all the world's ills? If I write my apps in Java/Kotlin using the official Android SDK, good luck trying to run my app on anything other than Android! FFS, just why KYS?

I love C/C++ and a tiny bit of Assembly when performance really matters. Historically, Qt has been all about C++, good as native while still 100% portable, and highly performant -- that's why I've loved Qt.