Qt Developers Discuss What To Do With All Their "P1" Priority Bugs

[oleid]

At this point, it is pretty bleak for Qt's code quality - they introduce new issues at a far higher pace than they solve existing ones.

Maybe they should just rewrite it in rust (duck-and-cover)

[bug77]

The company I'm working for is just about to throw that baby out, including the bathwater. I was the guy that introduced Qt to our company about 12 years ago. These days we are about to replace it with something else because of the constant issues we have with it. Granted, the times were not easy for what is now called "the Qt company". But instead of improving their core product we saw them literally dancing with every new fad in the industry: Automotive, Animation, Web etc. Instead of providing a solid build system they invented three "own solutions" until the finally admitted that they were unable to do it right and now grudgingly start to support CMake. QtQuick (as it is called today) is a similar issue.
All of that is just about the code base. Not talking about the support (yes we had paid support) or the licensing issues.

Well, you, as the end user, are entitled to use whatever toolkit works for you.
I was just saying, just because someone mismanaged the backlog is no grounds for a company that lives for one product to close up shop.

Fwiw, I had the same feeling that they're branching out too fast, but, unlike you, I have never programmed for/using Qt. I see I was not wrong. Also fwiw, companies have a duty to explore new things, lest they end like Microsoft scoffing at mobile two decades ago. They still need to get their priorities straight and allocate resources accordingly, tho.

[bug77]

Maybe they should just rewrite it in rust (duck-and-cover)

Technically not the worst idea, but we both know the code base is too big to be rewritten. In any language.
In unrelated news, I've just started doing precisely that (on a tiny project), maybe I'll have something running soon. (soon = a few months, I'm not that good with Rust)

[horizonbrave]

I just remember one of the latest episodes of a famous Linux show (maybe the one with Noah.. I forgot the title) they were all frothing about KDE latest release, KDE here KDE there.. like totally fan boys, everybody was raving about it. I found it so childish. I guess Gnome supporters must be doing the same, I just found it ridiculous consider ridiculous being a very popular show to polarize listeners like that, especially considering the little imperfections they were mentioning while lauding it (settings thrown everywhere for example). I just found it incredibly ugly looking desktop that reminds of my dark ages using Windows
But I confess that I'll might give it a try if they find a way to simplify settings or hiding advanced ones somewhere. Life is chaos already, I don't need that in a GUI!

[patstew]

The company I'm working for is just about to throw that baby out, including the bathwater. I was the guy that introduced Qt to our company about 12 years ago. These days we are about to replace it with something else because of the constant issues we have with it. Granted, the times were not easy for what is now called "the Qt company". But instead of improving their core product we saw them literally dancing with every new fad in the industry: Automotive, Animation, Web etc. Instead of providing a solid build system they invented three "own solutions" until the finally admitted that they were unable to do it right and now grudgingly start to support CMake. QtQuick (as it is called today) is a similar issue.
All of that is just about the code base. Not talking about the support (yes we had paid support) or the licensing issues.

What are you changing to?

[ed31337]

Oh yeah, Qt Quick / QML, "the future" of Qt... except its not. It's supposed to make everything easier, but you quickly end up wrestling with C++, QML and JavaScript at the same time, and then everything becomes more cumbersome, complicated and harder.

I couldn't upvote your comment enough. Qt Quick / QML as "the future" of Qt was a terrible decision. So glad to hear some other developers coming to the same conclusion as I. And it's not just the having to wrangle with C++, QML, and JavaScript at the same time, it's a threading problem on top of all that. Very hairy and very cumbersome, not worth my time. Stick with Qt Widgets and forget about Qt Quick / QML.

Unfortunately, the Qt Company is stuck with maintaining this huge Qt Quick / QML abomination now, spreading themselves too thin to fix all the P1 bugs like they should...

[arQon]

They are also sometimes swiping issues under the rug, I remember reporting one that was deemed P1, that idled for like couple of years before it was closed as "insufficient information", even tho it both explained the issue and provided a snipped to reproduce it...

Better known as the "Red Hat bug management policy".
Yes, it's a dishonest way to handle bugs, but suggesting that KDE is the only project to suffer from it is unfortunately very optimistic: GNOME practically invented the concept.

[schmalzler]

Technically not the worst idea, but we both know the code base is too big to be rewritten.

Solution: Declare the rust bindings as the new upstream Qt.
Would also make it easier then to further develop the rust-bindings.
Win-win!

[oleid]

In unrelated news, I've just started doing precisely that (on a tiny project), maybe I'll have something running soon. (soon = a few months, I'm not that good with Rust)

Cool! Care to elaborate? There are already a few projects I heard about, e.g. Iced, Druid, OrbTK, KAS (in no particular order). How would your experiment compare?

[oleid]

Solution: Declare the rust bindings as the new upstream Qt.
Would also make it easier then to further develop the rust-bindings.
Win-win!

Yes, that would definitely change everything for the better