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

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

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

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

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

[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

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

[ed31337]

Is PyQT better?

I don't know, having never used either one.

But I have used Riverbank Computing's QScintilla library. My initial impression of Riverbank Computing was that they have a very clean, nice looking website and they provide fairly good documentation.

Once I started using QScintilla, however, I ran into some bugs/roadblocks. I also didn't like their lack of LGPL licensing -- they obviously want you to pay them money for commercial use. Well, after digging, I found out that the base Scintilla library upstream from Riverbank has a very permissive license agreement, doesn't have the bugs/roadblocks I was running into, AND get this, the base Scintilla library has support for Qt bindings all by itself! The only thing it was lacking was a slick website advertising this feature and the documentation for it was a little more clunky at first glance.

I kind of felt a little bit cheated by Riverbank Computing. Their fancy website sort of lured me down a path that was more expensive than I might have been on otherwise.

Even though I don't have any horse in this PyQt vs PySide race, I am still rather pleased that the Qt project decided to work with PySide rather than Riverbank PyQt.

[timofonic]

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.

Is PyQT better?

[timofonic]

I would not advice anybody to use QT. It is very buggy, and the devs are more interested in bringing new features with even more bugs.
I give you one example of serious bug, that I was reporting nearly 5 years ago. The bug was confirmed, and tagged as "P2 Important".
It is still open today.
https://bugreports.qt.io/browse/QTBUG-43635

And then I contacted someone that is responsible for the QT development on Android , and he said, he can solve it, but it costs, if I remember correctly 7.000 or 7.500 euro, and that is the minimal fee that ask for solving a bug.

Does QT still belong to Trolltech? because that name really fits them.

This is such a buggy framework, and then on top it has this restrictive License.

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

[ed31337]

You're strongly suggested to use QML/Qt Quick Controls 2 for new developments instead, especially on Android.

Every time I've seriously tried to use QML/Qt Quick Controls 2, I've found it very frustrating and ultimately more trouble than it's worth. Qt Widgets might have a few ugly spots and minor bugs, but in my opinion, it's still far better than QML/Qt Quick Controls 2. It's rather unfortunate that the Qt developers view Qt Widgets as second class to their new QML/Qt Quick Controls 2.

Problems with QML/Qt Quick Controls 2:
1. Now I have to think in two different languages to get my work done (C++ for speedy app code and JavaScript/QML for user interface). With Qt Widgets, I have a very nicely designed, easy to extend, C++ only framework. It's just so much easier on my brain to stay in C++ and not deal with that Javascript/QML crap.

2. The Forms Designer in Qt Creator works pretty darned good for Qt Widgets, while it pretty much sucks ass for QML/Qt Quick Controls 2. The Qt developers seem to think I'm going to just whip out Javascript/QML code manually on my own without a forms designer. They may understand how to do that like the back of their hand, since they wrote QML/Qt Quick Controls 2, but for me it's like learning a foreign language.

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.