Announcement

Collapse
No announcement yet.

Qt 5.9 Feature Freeze Soon, Adds Experimental Qt Quick OpenVG Backend

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

  • Qt 5.9 Feature Freeze Soon, Adds Experimental Qt Quick OpenVG Backend

    Phoronix: Qt 5.9 Feature Freeze Soon, Adds Experimental Qt Quick OpenVG Backend

    While Qt 5.8 was just released yesterday, the feature freeze is already upon us for Qt 5.9 due to the v5.8 release having been dragged out from November to this week...

    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
    QT is adding all kind of new features, instead of cleaning and resolving all the horrible bugs it has. I have reported some bugs, related to android (transparency in UI doesn't work), it was confirmed, it was flagged as "Critical", years later, it's still the same.
    Qt3D after years of development is with all incredible bugs, and I wonder how they where not discovered before me, since I'm a novice at Qt3D. My intention was just to play with it and to see how it works and if it has potential. [Not to speak about the lack of Documentation of Qt3D for c++]
    Another sad point is that the QT API makes heavy use of raw pointers and no smart pointers.
    I would prefer, that QT would take a break introducing new stuff, and therefore spending more time on modernizing the API and fixing bugs.
    Not only new stuff with new bugs are introduced, but also many regressions are visible.
    And here I have to give credit to haiku-os : they are in lake of developers, and going to a harder time, but one would report the bugs I have reported to QT, these kind of critical bugs would be solved like in 1-2 days, and already the next day ready for trying the fix in a new nightly built.

    Comment


    • #3
      Yeah, I'd have to second that, I've reported a number of bugs which have been deemed critical, many involving hard crashes, not a shred of work has been done, the oldest is almost 2 years old now. They are too focused on introducing new bugs, or trivial UI elements that might be a welcome addition to newcomers, but entirely redundant to adept users who have long developer their own controls, or new half-baked barely needed by anyone features.

      Unfixed critical bugs alone are currently over 500 in Qt. Not to mention numerous design flaws and limitations. But yeah, fixing those would actually require a tremendous effort, including redesign of the foundation and everything above it, much harder than adding even more stuff on top of a crooked foundation. Let's see and wait how long will that last before it crumbles, I just hope long enough to migrate my work away from it.

      There is Qt 5.6 which was chosen for LTS, however it is neither particularly long term nor in a particularly better shape than the leading branch. So committing to it, the benefits are outweighed by the new features in 5.7 and to a lesser extent 5.8, some of which actually happen to be useful.

      Comment


      • #4
        Some things like changing the API can obviously only be done with the next major version and there will always be a compromise between new and compatibility to make porting easier.

        Some of the areas of work are also not interchangable as there are multiple contributors to Qt.
        I.e. work/people cannot be asssumed transferable between modules as different companies might be involved.

        E.g. work that BlackBerry invests in the QNX platform plugin is not available to the Qt Company for bugfixing something else.
        BlackBerry might decide to put some resources onto bugfixing elsewhere, but they also might not.

        Cheers,
        _

        Comment


        • #5
          What's up with all those Qt complaints? I mean: I'm not anti-anything, it's just that lately I've read so many posts on this forum smashing GTK to smithereens and instead praising Qt, but now...

          Comment


          • #6
            Look for example this trivial example , what a horrible bug reported in 2014!


            Nobody ever in his life tried a ListView on QT on Android in "Edit Mode"?
            The Text when editing is cut, looks horrible, is not readable.
            Something basic like this is not working??? And even on Android, and we know how important is Android today, and was also in 2014!.
            If something horrible like this would ever be reported for example to haiku-os , this visual bug would be resolved immediately after the confirmation of the bug, not even a day such a bug would survive in haiku-os.
            And QT? Years later nobody cares about it.
            What was the solution an important developer from KDAB (a company working for QT) gave me:
            1) Write the UI in QML not C++ 2) Pay us 7500 Euro and we fix it 3)......

            I was thinking: 7500 Euro? No way, I just report it, anyway i can wait for the next release, is not urgent..

            Now look at the next bug, also about 2 years old:


            Somebody is so annoyed by this bug, that he says clearly that this should be flagged as a blocker.
            A really horrible bug, and you can not make pretty UI in Android with that bug present. Years later still no activity on it!

            Look this bug, which was flagged just as "Somewhat Important"


            Yes, might not sound very important that you can not paint with anti-aliasing. The result is horrible unsmooth drawings. And this on Android, where people expect everything to be pretty and smooth!

            This people are completely ignoring Android??????

            Comment


            • #7
              Originally posted by cipri View Post
              Look for example this trivial example , what a horrible bug reported in 2014!


              Nobody ever in his life tried a ListView on QT on Android in "Edit Mode"?
              It is a desktop widget. It is not really expected to be used on a non-desktop. I wouldn't expect any of the desktop widgets to work on embedded or mobile devices, and wouldn't bother testing it as I am sure they just don't work in any sane way. The work on fixing your issue has basically gone into making Quick Controls 2 (it is a working title), which are controls aka widgets designed for mobile and embedded use.

              Comment


              • #8
                Originally posted by carewolf View Post
                It is a desktop widget. It is not really expected to be used on a non-desktop. I wouldn't expect any of the desktop widgets to work on embedded or mobile devices, and wouldn't bother testing it as I am sure they just don't work in any sane way. The work on fixing your issue has basically gone into making Quick Controls 2 (it is a working title), which are controls aka widgets designed for mobile and embedded use.
                This is not the point! You can also use Android as Desktop (also android x86 etc) with big screen. And if it would be like you said, then the admin should have closed the bug "wont fix".

                The point is, that QT is introducing new stuff without minimal testing (Qt3D if you want a non-mobile example)! QML/QT Quick, I don't know, since I don't use such languages. This is why I spend time with QT, because of the promise of cross platform, and if you can expect one platform to be well supported, then it should be android. Why the haiku-os own made port of QT to haiku works better than the QT Port to Android done by QT??????? This is commercial product, people are payed to code for QT, they are making money... and still such horrible bugs that are confirmed as critical and not touched in years????
                For what I should waste the time and write bug reports? Why is a bug flagged/marked as critical and not touched?? It's critical or not????

                Comment


                • #9
                  Originally posted by carewolf View Post
                  It is a desktop widget. It is not really expected to be used on a non-desktop. I wouldn't expect any of the desktop widgets to work on embedded or mobile devices, and wouldn't bother testing it as I am sure they just don't work in any sane way. The work on fixing your issue has basically gone into making Quick Controls 2 (it is a working title), which are controls aka widgets designed for mobile and embedded use.
                  I just tried it on a desktop running android. Still the same bug.
                  It's not about desktop or not desktop (because it's not a bug related to any kind of screen size or input method .. etc...
                  These are just bugs with no excuse of not fixing. And one of them is a bug which didn't exist, and now that it appeared, it broke the apps of the developers. (the problem with the transparency for example). Ok, regressions happen. But 2 years not looking at it? Why was it flagged as critical? It's critical but it's totally ignored?

                  Comment


                  • #10
                    Originally posted by cipri View Post

                    This is not the point! You can also use Android as Desktop (also android x86 etc) with big screen. And if it would be like you said, then the admin should have closed the bug "wont fix".
                    It hasn't been closed as wontfix. The work going into solving it has just gone to where most Android users are: On mobile devices.

                    Comment

                    Working...
                    X