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

[cipri]

Sounds like a great idea. Are you gonna rewrite Qt to Rust, right after you figure out how to do Rust/C++ interop, which is still on a -maybe- TODO list for the Rust team? Or are you just gonna go bold and deliver on a Rust-based GUI middleware library? Got a few years to spare, no family and someone to pay your day to day bills ? Awesome - do it!

No. I'm in the process of writing my own Tool-Kit. Everything based on Vulkan and Wayland. I start barely with the Wayland Protocol. Initially I started with libwayland-client, which is a ugly c-library. And to build on top of that a nice library with a c++17 API. But I noticed I had to write a ugly code to hide the sh*t of libwayland-client. This was an option, but later when you want to port everything to android/windows/haiku/FuchsiaOS etc... you have to port the sh*tty c-library anyway.... So with modest effort I have my own c++ wayland-client library with c++17 API.
Why did wayland such a long time to develop?? Because of the many bad open-source developers, which many of them don't like or even hate c++. Check on the official wayland page, the last documentation is wayland 1.3, while the current wayland version is 1.9 . Not to mention obsolete documentation which is not in sync with the implementations..

After I'm happy with my c++17 GUI Framework I will start writing my own Wayland composer, again with at least c++17 and based only on the Wayland Protocol.
Why also writing also the wayland composer/server ? Because if it's written nicely in c++, porting it is a lot easier.
And when I'm happy with the composer, I will extend it, such that the clients can draw directly with vulkan, without having to use egl.
Like this I will be restricted to Vulkan, but anyway all my devices are working fine with vulkan, and anyway vulkan is the future (already android is supporting vulkan out of the box, i think starting with version android 7 )
And after I have done this, and Gnome or KDE continue making me angry, I will take Debian, and write my own Desktop.
This seems like a lot of work, not?? NO!! It's not! It's a lot of work if you build on top of ship, and you work hard to work around bugs and bad design!
Kurt Skauen built AtheOS from scratch, everything done by himself in about 5 years. But he wrote also the Kernel, the drivers, everything.... and all this in his free time.
Compared to that, starting with Debian, having all the drivers already working is not such a big deal.

[MartinN]

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

Sounds like a great idea. Are you gonna rewrite Qt to Rust, right after you figure out how to do Rust/C++ interop, which is still on a -maybe- TODO list for the Rust team? Or are you just gonna go bold and deliver on a Rust-based GUI middleware library? Got a few years to spare, no family and someone to pay your day to day bills ? Awesome - do it!

[cj.wijtmans]

Even on X11 Plasma is in a regressed state. at login it locks up and i have to wait an hour before panels show up or programs launch correctly.

[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

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

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

[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 ?????

[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?

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

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