Been using Linux as sole OS for 25 years now. I will stick to X11 no problems, I am sure it will be just fine for my usage. When we thought Gnome 2 was gone, MATE fork appeared, X11 will be there for a long time. I am also going through the struggle of porting a software I maintain (github.com/edumucelli/docking) to Wayland and it is awful: "this compositor do this part, that one does that part, no compositor does this :shrug".
Preparing for KDE Plasma's Last X11-Supported Release
211–220 of 392 posts
Re: Preparing for KDE Plasma's Last X11-Supported Release
#212What's sad is that after many years Wayland still lacks several things/features that X11 has/allows. Some of them are intentionally not implemented because of security paranoia. For example, Chrome "picture in picture" window doesn't stay on top when I click somewhere else since Wayland doesn't allow windows to stay on top. If I had a lot of time I could list how Wayland breaks many applications. Not saying that X11…
I have a virtual pinball cab with two (and soon) three displays. Wayland really makes life difficult here because the software needs to always put the playfield on one display, the backglass on another, and the "dot matrix display" window on a third. That's a big no-no with Wayland. Fortunately KDE has window rules as a workaround. Sway and Hyprland allow similar rules. Mutter on Gnome has no equivalent. I'm guessing…
That's strange; you should be able to do that with the standard xdg-shell protocol, though I suppose it depends on the app's behavior. The app can tell the compositor which output to fullscreen each window on.
Alternately, if it's using layer-shell windows, those can also be pinned to a specific output.
If it's not layer-shell, and the windows aren't fullscreen, then yes... it's annoying. The xdg-session-management protocol will likely fix that in this particular case (at the expense of having to manually place the windows in the right places once, and then it can remember in the future), but that protocol has just recently been stabilized and of course no one supports it yet.
It's all so frustrating watching the Wayland folks reinvent everything, poorly, and after more than 10 years it's still not there yet.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#213Earlier quoted context omitted.
But users do not want to have to toggle that for every PiP video they watch. Its why I am still on X11
I can't speak for Gnome, but KDE makes it pretty easy to create rules that apply automatically to any new window that meets whatever arbitrary criteria you set.
That's terrible. That's an "unbreak my software" preference. User's shouldn't have to mess with that; things should just work in ways they expect, out of the box.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#214As someone who shipped my fair share of critical production features, I find this plan raising my eyebrows somewhat. Disabling a feature AND simultaneously removing the codebase for that feature almost never ends well. There will always be some use cases that people haven't thought of. In serious projects (read, your career is at stake) a much better strategy is to first make the feature unavailable by normal means w…
The problem with that strategy when it comes to desktop software is there's no way for the developer to know what the user has done (unless the software phones home, which is a no-no when it comes to privacy-respecting open source software).
If it's a SaaS API or a web application, the developers can look at access logs or analytics to determine what endpoints and features are being used, and when users need to go back to the deprecated interfaces to get what they want.
There's no way for a KDE developer to learn "$NUMBER users went back to X11 because $FEATURE is missing in the Wayland version".
(Of course they can ask their users, or hope that users file issues on the bug tracker, but things will definitely fall through the cracks via these imperfect communication channels.)
Re: Preparing for KDE Plasma's Last X11-Supported Release
#215Sadly, recent GNOME versions introduced a hard dependency on systemd and can no longer be used on systemd-free distros. This is the kind of problem that the anti-systemd people had in mind back then when debates about systemd raged.
I'm sorry, but are we still going on about this? I love a good debate as much as the next guy, but being able to just have one interface (systemd's) for all services and having a more-or-less consistent language really helps.
At this point, it's simply a bit too late. I'm sure in the early days it was still a choice, but when you want prepackaged things, you get systemd.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#216Earlier quoted context omitted.
What did you learn when you checked the logs to see what was wrong?
Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!
Log in using wayland -> no desktop. Log in using x11 -> desktop. Clearly it's "wayland related" even if whatever root cause it is is something you wouldn't consider directly attributable to it. Logging into a graphical session is something that has just worked out of the box each other install on whatever random hardware I've used for many years. How is that classified as some nitpicky "new thing bad" complaint?
Re: Preparing for KDE Plasma's Last X11-Supported Release
#217Earlier quoted context omitted.
On the other hand, I recently installed a system with debian 13, and it was really easy to distinguish between X11 and wayland sessions: if the session displays a plasma desktop, it's X11, if it crashes on login, it is wayland. YMMV if you try to switch to wayland.
You might have an older GPU that doesn't work with wayland like me. My Radeon HD5870 also won't do Vulkan and anything wayland has never worked properly for me.
I'm not questioning what you are saying, but Wayland's only requirement is DRM, which is a Linux kernel capability that is supported for basically everything that you can push some sort of display cable into. It's for buffer management, and X was also ported to use this API.
Unless you have proprietary X server blobs, you have mostly the same low level route in either case to display stuff, so it's on the exact compositor you have tried, not on the wayland protocol.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#218Earlier quoted context omitted.
Probably didn't even bother to diagnose the issue. It's hard to tell if it was even wayland related without logs and some digging. But lets just blindly blame wayland cause new thing bad!
Log in using wayland -> no desktop. Log in using x11 -> desktop. Clearly it's "wayland related" even if whatever root cause it is is something you wouldn't consider directly attributable to it. Logging into a graphical session is something that has just worked out of the box each other install on whatever random hardware I've used for many years. How is that classified as some nitpicky "new thing bad" complaint?
Well, it's like new car doesn't start but you have forgotten to put fuel into it, and now blame the car.
This is Linux desktop, like if you have never had a black screen before then I'm not sure what you expect. One culprit could actually be the home .config/.cache folders that have all kind of sh*t accumulated (like why do we still do it this way? It's horrible), so I usually rename them and try again to see if this is the problem behind the scenes.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#219Earlier quoted context omitted.
If you use KDE, you can work around this because of the powerful feature set the window manager has for setting custom window behavior. 1. Right click the PIP window and then click "More Actions-> Special Window Settings". 2. On the window that pops up, click "Add Property", and add "Window title". Change the drop-down from "Unimportant" to "Exact match" (this works on Firefox because the window title is always "Pict…
Not too bad? A hidden procedure with ten clicks, which the user has to repeat for each web browser. And it may break at any time if the browser changes some details. Or if KDE changes. And it's specific to KDE, with no alternatives in most Wayland WMs. All that for _one_ feature which works out-of-the-box with Xorg, and which Wayland removed for security reasons. From what I've seen, sharing the screen is another com…
> I have faith in Debian for filtering out rogue applications
Sorry but all I can say to that is: lol
As for security, it's easy/possible to cut holes into a solid wall. But if your whole system is swiss cheese, you can't plug all of them in. Wayland is a solid wall where protocols are the means to cut new holes. Sure, protocol development is slow (at least their acceptance), but this is the proper way to do it.
And even if you have faith in your applications, do you also have faith in your data? Because it's a mostly C/c++ application set, one vulnerability is enough to make them malicious. And with the beautifully engineered default "GNU/Linux" userspace security model, the only thing a random script can't do on your machine is install a new video card driver. But everything else is under the same user and readily accessible with full network access.
Re: Preparing for KDE Plasma's Last X11-Supported Release
#220Been using Linux as sole OS for 25 years now. I will stick to X11 no problems, I am sure it will be just fine for my usage. When we thought Gnome 2 was gone, MATE fork appeared, X11 will be there for a long time. I am also going through the struggle of porting a software I maintain (github.com/edumucelli/docking) to Wayland and it is awful: "this compositor do this part, that one does that part, no compositor does th…
I have a feeling xorg will still be there, when devs have moved on from wayland to the next new thing.