Originally posted by timofonic
View Post
Announcement
Collapse
No announcement yet.
Qt 6 Will Bring Improvements To The Toolkit's Python Support
Collapse
X
-
Originally posted by habilain View Post
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.
Comment
-
Originally posted by ed31337 View Post
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.
- Likes 4
Comment
-
Originally posted by ed31337 View PostProblems with QML/Qt Quick Controls 2:
I don't like javascript
it's the only recommended approach for Android
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.
Comment
-
Originally posted by miabrahams View Post
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++.
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.
Comment
-
Originally posted by Kernelcoffee View PostI don't like javascript
FTFY
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.Last edited by ed31337; 20 August 2019, 04:28 PM.
- Likes 1
Comment
Comment