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

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    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.

    Comment


    • #3
      Is that the same as PyQt?

      Comment


      • #4
        Originally posted by FireBurn View Post
        Is that the same as PyQt?
        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


        • #5
          Originally posted by habilain View Post
          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.
          AFAIK Nokia wanted to buy PyQt to get complete control and both couldn't come to an understanding which is probably code for "Riverbank wanted more money" or so.

          Comment


          • #6
            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.
            I just want to point out here that you're complaining that the platform they declared finished near the end of the 4.x series has issues with a platform it was never really designed to support. You're strongly suggested to use QML/Qt Quick Controls 2 for new developments instead, especially on Android.

            Comment


            • #7
              Originally posted by Luke_Wolf View Post
              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.

              Comment


              • #8
                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...

                Comment


                • #9
                  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?

                  Comment


                  • #10
                    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.

                    Comment

                    Working...
                    X