The Regressed State Of KDE Plasma On Wayland, But Things Should Get Better

[cipri]

What value does rewriting it without give you?

You are right! But the longer you wait, the more you continue stacking on sh*t, the more time you loose, and in the end it will come to the same solution, removing QT.
I know this very well, since I wasted a lot of time with QT, and building on top of sh*t. I don't see any hope of QT to change. Also the new Vulkan stuff introduced by QT, exactly like the new "QT3D" has the same old-fashion, horrible, and hard to maintain API. [The reason is consistency. Consistency is good and important, but not when aiming for being consistent with sh*t].
And what does rewriting bring? Easy: The earlier, the less painfull it will be. QT is introducing all the time new features.... mostly experimental and full of bugs. And you spend time with QT, you build on top of it, then you inevitably get across the horrible bugs, you make a bug report, it's flagged as "critical". At this point your hopes are big for a bug-fix, till comes the disillusion and many years later you still have to notice that it was not touched in any sense. You are stuck, and then you can choose.... to learn all the Qt internals, understand all the sh*t and try to fix it yourself, then you hope that your fix will be merged, you wait again... and with big chances that nobody cares. Then you can choose to have your separate QT, which gets out of sync with the original.. etc... etc... it's like a chain reaction of sh*t. And in the end you have to notice..... that with all that effort and lost time, you could have written the needed tools yourself and not depending on qt anymore.
Even you get past a horrible qt bug,.... the next ones are around the corner... and you depend on a 90s style c++-API, which makes your own code more complicated, harder to maintain and watching out for leakages of the raw pointers... (especially for the newer additions with less documentation, where it's not clear to whom the raw pointers belong.... to you or to the qt framework which might do the destruction, etc......)

A nice story, somehow related: https://medium.com/message/everythin...n-81e5f33a24e1

cipri

[boxie]

You are right! But the longer you wait, the more you continue stacking on sh*t, the more time you loose, and in the end it will come to the same solution, removing QT.
I know this very well, since I wasted a lot of time with QT, and building on top of sh*t. I don't see any hope of QT to change. Also the new Vulkan stuff introduced by QT, exactly like the new "QT3D" has the same old-fashion, horrible, and hard to maintain API. [The reason is consistency. Consistency is good and important, but not when aiming for being consistent with sh*t].
And what does rewriting bring? Easy: The earlier, the less painfull it will be. QT is introducing all the time new features.... mostly experimental and full of bugs. And you spend time with QT, you build on top of it, then you inevitably get across the horrible bugs, you make a bug report, it's flagged as "critical". At this point your hopes are big for a bug-fix, till comes the disillusion and many years later you still have to notice that it was not touched in any sense. You are stuck, and then you can choose.... to learn all the Qt internals, understand all the sh*t and try to fix it yourself, then you hope that your fix will be merged, you wait again... and with big chances that nobody cares. Then you can choose to have your separate QT, which gets out of sync with the original.. etc... etc... it's like a chain reaction of sh*t. And in the end you have to notice..... that with all that effort and lost time, you could have written the needed tools yourself and not depending on qt anymore.
Even you get past a horrible qt bug,.... the next ones are around the corner... and you depend on a 90s style c++-API, which makes your own code more complicated, harder to maintain and watching out for leakages of the raw pointers... (especially for the newer additions with less documentation, where it's not clear to whom the raw pointers belong.... to you or to the qt framework which might do the destruction, etc......)

A nice story, somehow related: https://medium.com/message/everythin...n-81e5f33a24e1

cipri

as was said, it would be better to start the project from scratch than to remove QT.

[ssokolow]

you talk so because don't know the benefits of wayland if implemented in every single elements of the operating system utilities and so on. The fanboy doesn't accept the progression if not understands it.

Actually, I'm very much aware of the benefits of Wayland and I've been looking forward to it for years. I could even write up a long list of specific X11 things which bother me which Wayland will fix.

(And I was the one who actually chimed in on the mailing list to remind them about making the system idleness count for the screensaver aware joystick/gamepad input when a proposal was made for a Wayland joystick/gamepad protocol.)

... I'm just very particular about how my desktop should look and feel and not only has GNOME has been drifting ever further from that, they haven't proven that they're able to avoid causing regressions in GTK+ 3.x when it's used to build more traditional desktops.

(Which is why my own coding efforts have switched from targeting PyGTK (GTK+ 2.x, the closest thing to a universal Linux toolkit at the time) to PyQt (Qt 5), regardless of the desktop they're expected ot run on.)

TL;DR: I'm well aware of the benefits of Wayland. The downsides of GNOME dwarf the benefits of Wayland, so I'm waiting for a non-GNOME way to run Wayland on top of the nVidia binary drivers I use to get work done.

Wayland is much more efficient than x11. One only distro uses it because the other distros are not ready for wayland.

I use a blend of LXDE, and KDE, and desktop-independent components, specifically to maximize efficiency and responsiveness within the limits of the features I need.

(ie. I start with LXDE, strip out anything that can be replaced with a lighter but less featureful solution, such as replacing LXTerminal with urxvt and kuake.pl, and then bring in the KDE components I can't live without, such as Filelight (Baobab's radial view is a very poor clone of it), K3b, and, when working with heterogeneous monitors, Plasma (LXPanel doesn't support "divide a taskbar across multiple panels on the same edge" and not all my systems can get the bottom edge of all the monitors to line up so they can share a single, very long panel).)

Trust me when I say that moving to GNOME would bloat my system up and slow it down more than moving to Wayland would slim it down and speed it up.

[ssokolow]

I have stressed already so many times, that in my opinion one should remove the QT dependency.

Not going to happen.Even if they were to rewrite the entire desktop (Trust me. It'd be easier to rewrite in a different language than a different application framework, since the former is a more mechanical operation.), it'd still be a regression.

As someone who has written software using both GTK+ and Qt, I am qualified to say that Qt is technically superior in many ways and that, once you've gotten used to what Qt gives you, GTK+ feels downright primitive. (And while I haven't used them anywhere near as much, I can also say that other APIs like wxWidgets are even worse.)

An example I love to share, since everyone can relate to it, is persisting UI customizations. GTK+ is still catching up to what Qt has had for ages (since at least Qt 3.x for toolbars/panels and Qt since 4.2 for window geometry).

1. Toolbars and panels have built-in support for being torn-off, docked elsewhere on the window, or hidden/shown via a default context menu (and you can disable tear-off or limit where docking can occur via simple bitflags that are exposed as checkmarks in Qt Designer.)
2. QMainWindow allows you to save or restore the state of all toolbars and panels to/from a string with a single function call.
3. QMainWindow allows you to save or restore window geometry (size and position) to/from a string with a single function call.
4. QSettings allows you to create a key/value store which will accept QMainWindow's persisted settings with only a line or two.
5. QSettings automatically handles batched/deferred writes with a combination of "flush on timeout" and "flush on quit" behaviour.
6. QSettings automatically finds the system-standard place to put the application config file and supports a fallback chain that not only allows system-wide configuration, but also allows configuration files that apply to all products made by the same vendor.

Now, I mainly code against PyQt, since I don't trust myself to write reliable C++, but, from my perspective as someone who wants to produce the best possible end-user experience, Qt is "the best of a bunch of s**tty options" by a country mile.

[schmalzler]

You are right! But the longer you wait, the more you continue stacking on sh*t, the more time you loose, and in the end it will come to the same solution, removing QT.
I know this very well, since I wasted a lot of time with QT, and building on top of sh*t. I don't see any hope of QT to change. Also the new Vulkan stuff introduced by QT, exactly like the new "QT3D" has the same old-fashion, horrible, and hard to maintain API. [The reason is consistency. Consistency is good and important, but not when aiming for being consistent with sh*t].
And what does rewriting bring? Easy: The earlier, the less painfull it will be. QT is introducing all the time new features.... mostly experimental and full of bugs. And you spend time with QT, you build on top of it, then you inevitably get across the horrible bugs, you make a bug report, it's flagged as "critical". At this point your hopes are big for a bug-fix, till comes the disillusion and many years later you still have to notice that it was not touched in any sense. You are stuck, and then you can choose.... to learn all the Qt internals, understand all the sh*t and try to fix it yourself, then you hope that your fix will be merged, you wait again... and with big chances that nobody cares. Then you can choose to have your separate QT, which gets out of sync with the original.. etc... etc... it's like a chain reaction of sh*t. And in the end you have to notice..... that with all that effort and lost time, you could have written the needed tools yourself and not depending on qt anymore.
Even you get past a horrible qt bug,.... the next ones are around the corner... and you depend on a 90s style c++-API, which makes your own code more complicated, harder to maintain and watching out for leakages of the raw pointers... (especially for the newer additions with less documentation, where it's not clear to whom the raw pointers belong.... to you or to the qt framework which might do the destruction, etc......)

A nice story, somehow related: https://medium.com/message/everythin...n-81e5f33a24e1

cipri

You write quite some sh*t there Really. Your point is that you aren't happy with Qt. Not a single argument in all your writing. Not a single one! Just baffling how bad Qt is and that it is sh*t and unreliable and so on.
I NEVER had an issue with Qt. Well, not entirely true, there were small things from time to time usually fixed rather quick, especially Gentoo sometimes added patches when the fix was OK. On the other hand I had my issues with GTK. firefox crashing when selecting an application to open a downloaded file. And the ingenious solution for "single click" in file dialogs [1] - this is the main reason I will never write an application in gtk and only use them when really needed... And they don't intend to fix it... I so often select files unintentionally because I click on a previously selected file (often selected automatically while navigation to that directory) or am off by one click while double clicking.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=758065 - which basically is the result of trying to "workaround" [2]
[2] https://bugzilla.gnome.org/show_bug.cgi?id=121113 - 14 years old bug and still no working single click in gtk file dialogs...

[hiryu]

I think the most interesting question here is why Qt apparently decided to violate the promise of interface stability (things working like documented), which is presumably the reason the KDE Wayland experience has regressed?

If you can't depend on the foundation on which you build your house, your house won't stay standing for long. This is, I believe, what Martin's post was *really* about: How to ensure that KDE doesn't get screwed over by Qt changing an important (and guaranteed stable?) implementation detail in the future.

Martin was being polite about it, but my impression is that he's actually quite pissed with Qt on this particular point. And even so, he *still* tried to remain constructive and took great pains to point out that if Qt could be arsed to use KDE's extensive, free and open source testing suite, issuess like these would be caught a lot earlier.

So how about it Qt?

I think ermo nails it here. The situation with Qt 5.x seems like it has been shit for quite some time, and that Martin is still trying to be constructive here without burning any bridges.

And really, it hasn't just been issues with Wayland either. I remember having issues with multiple screens, especially when resuming from sleep. I believe both those issues were due to, at least in part to qscreen:

https://blog.martin-graesslin.com/blog/2016/07/multi-screen-woes-in-plasma-5-7/

Often, it is not until these glaring bugs are fixed on the Qt side that bugs further down the pipeline on the KDE side for the corresponding issues can be fixed. I don't recall Qt being so problematic in the past for KDE for Qt 4.x and earlier (I've been using KDE since the 1.1.x days).

Does anyone know what's going on here? Is it that Qt's current owners (The Qt Company) really just don't care about Linux anymore? Are they over extended? Other reasons? Some combination of reasons?

[cipri]

our point is that you aren't happy with Qt. Not a single argument in all your writing.

Yes, I didn't become specific, because I wrote already in other posts about bugs and problems, and I don't want the people to become bored and call me repetitive. But yes, I gave in fact an argument: Ancient API (many raw pointers, and not always clear to whom they belong, and who is supposed to do the destruction) ! Check Qt3D with all the bugs..... check the Android Port... (Just the bugs that I was reporting...being flagged as critical. Who can imagine that a "critical bug" in the Android port would not get any attention?? All the bugs that make an Android c++ app nearly impossible, because you are force to have ugly GUI (transparency bugs), etc...
QT is good enough if you have something simple, and you just want to have it work somehow .
I'm also doing programming of microcontroller, which is mostly the domain of assembler and C. My libraries and code for the microcontroller (my own hardware abstraction layer) have a c++14 api !!! And these "modern toolkits" have api of the c++ of the 90s ?????

[Geopirate]

... what I meant was that I do not rush into wanting wayland that at user level changes little or nothing. I am not saying that wayland is bad, but simply that in this development phase it is normal for dev to encounter problems and regressions. It will take years before the wayland will definitively replace Xorg. GNU / Linux is not just Gnome, but Kde, Xfce Lxqt, etc. Without counting driver issues. But to the end user these things matter little, the important thing is that things work well that either Xorg or Wayland does not matter.

This is true, but there is a significant time to market advantage for Gnome Wayland adoption. Fedora made the move last year and Ubuntu will next year. No this isn't all of Linux, but it's a significant amount. Mint, Red Hat and Suse will follow suit and that will make a significant amount. Arch is a vocal minority, but there are there already too.

If you look for software that isn't in the repositories, you'll find a .deb, an .rpm and maybe something else.

[doom_Oo7]

My libraries and code for the microcontroller (my own hardware abstraction layer) have a c++14 api !!! And these "modern toolkits" have api of the c++ of the 90s ?????

what would you change ? Qt supports a lot of modern C++ stuff. Lambdas, rvalue refs, etc...

[dkasak]

Not going to happen.Even if they were to rewrite the entire desktop (Trust me. It'd be easier to rewrite in a different language than a different application framework, since the former is a more mechanical operation.), it'd still be a regression.

As someone who has written software using both GTK+ and Qt, I am qualified to say that Qt is technically superior in many ways and that, once you've gotten used to what Qt gives you, GTK+ feels downright primitive. (And while I haven't used them anywhere near as much, I can also say that other APIs like wxWidgets are even worse.)

An example I love to share, since everyone can relate to it, is persisting UI customizations. GTK+ is still catching up to what Qt has had for ages (since at least Qt 3.x for toolbars/panels and Qt since 4.2 for window geometry).

1. Toolbars and panels have built-in support for being torn-off, docked elsewhere on the window, or hidden/shown via a default context menu (and you can disable tear-off or limit where docking can occur via simple bitflags that are exposed as checkmarks in Qt Designer.)
2. QMainWindow allows you to save or restore the state of all toolbars and panels to/from a string with a single function call.
3. QMainWindow allows you to save or restore window geometry (size and position) to/from a string with a single function call.
4. QSettings allows you to create a key/value store which will accept QMainWindow's persisted settings with only a line or two.
5. QSettings automatically handles batched/deferred writes with a combination of "flush on timeout" and "flush on quit" behaviour.
6. QSettings automatically finds the system-standard place to put the application config file and supports a fallback chain that not only allows system-wide configuration, but also allows configuration files that apply to all products made by the same vendor.

Now, I mainly code against PyQt, since I don't trust myself to write reliable C++, but, from my perspective as someone who wants to produce the best possible end-user experience, Qt is "the best of a bunch of s**tty options" by a country mile.

I've also used both, and have to disagree. Your examples of convenience functions for getting / setting geometry values etc are things I've implemented in my projects in a couple of lines of code. I question whether these are the major advantages you're suggesting, or just some random convenience functions ... let's call them "bloat" ... thrown in to tick some boxes in a list similar to what you're compiled. Most app developers would merge this stuff into whatever config file / database / whatever they're using, and so the implementation is different per app. As for breaking out dockable toolbars and panels ... you're right ... gtk+ doesn't have this. I have never ever EVER *EVER* wanted to do this, as a developer, or as a user. I guess if you're building apps where this is for some reason required ( maybe you can't lay things out in a sane fashion, and give your users the job of implementing a layout that works ), then this is a big plus.

Anyway, love your examples ... love your work