Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    Adding to the interesting objectives for Qt 6 are further enhancements to "Qt for Python" for enhancing the programming language's support for this tool-kit...

    http://www.phoronix.com/scan.php?pag...thon-Qt6-Items

  • ed31337
    replied
    Originally posted by Kernelcoffee View Post
    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.
    Last edited by ed31337; 08-20-2019, 04:28 PM.

    Leave a comment:


  • ed31337
    replied
    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++.
    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.

    Leave a comment:


  • Kernelcoffee
    replied
    Originally posted by ed31337 View Post
    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.

    Leave a comment:


  • miabrahams
    replied
    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.
    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++.

    Leave a comment:


  • FireBurn
    replied
    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.
    Thanks for explaining

    Leave a comment:


  • carewolf
    replied
    Originally posted by timofonic View Post

    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.

    Leave a comment:


  • ed31337
    replied
    Originally posted by timofonic View Post

    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.

    Leave a comment:


  • timofonic
    replied
    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.
    Is PyQT better?

    Leave a comment:


  • timofonic
    replied
    Originally posted by cipri View Post
    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...

    Leave a comment:

Working...
X