Preparing for KDE Plasma's Last X11-Supported Release • Hacker News Board

Re: Preparing for KDE Plasma's Last X11-Supported Release

#201

Post by tosti » Wed, Jun 03, 2026, 5:26 AM UTC

rendaw wrote: post #199

lunixbochs wrote: post #189

Earlier quoted context omitted.

Hi, I'm the developer of Talon. It's possible to do the simple compositor specific hacks from Talon's scripting system to give yourself partial Wayland support at roughly the quality I'd be able to provide myself, and I know of a couple efforts to do this. The tentative plan for "dropping support for X11" is just to do one more public Linux X11 release, stop there, leave it available to download, and make it very cle…

This seems like it basically confirms ggp's complaints: You're not interested in addressing customers' needs, or giving them ways to address their needs themselves, and are instead taking a "if this doesn't meet my standards you're not allowed to do it" standpoint. If slack interactions are so unpleasant, why do you direct all support through it? Is there no way you could say "yes this is a hack, but we'll live with…

Do you have your logic inverted? Wayland is taking away accessibility. You can't blame any isv for that.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#202

Post by lunixbochs » Wed, Jun 03, 2026, 5:30 AM UTC

rendaw wrote: post #199

lunixbochs wrote: post #189

Earlier quoted context omitted.

Hi, I'm the developer of Talon. It's possible to do the simple compositor specific hacks from Talon's scripting system to give yourself partial Wayland support at roughly the quality I'd be able to provide myself, and I know of a couple efforts to do this. The tentative plan for "dropping support for X11" is just to do one more public Linux X11 release, stop there, leave it available to download, and make it very cle…

This seems like it basically confirms ggp's complaints: You're not interested in addressing customers' needs, or giving them ways to address their needs themselves, and are instead taking a "if this doesn't meet my standards you're not allowed to do it" standpoint. If slack interactions are so unpleasant, why do you direct all support through it? Is there no way you could say "yes this is a hack, but we'll live with…

I don't think any of your points reflect what I was trying to communicate.

> You're not interested in addressing customers' needs

I would love to support Wayland, but it is my position that it is impossible to "support Wayland" for Talon. I can only support a subset of the features and only on specific compositors, and it would be a lot of work.

> or giving them ways to address their needs themselves

As I said at the top of the message you are replying to, I believe today users already have the tools to address their needs themselves with about the same level of jank I'd be able to provide on Wayland. If this is a veiled hard line on open source being the only way for users to address their needs themselves, we have a philosophical difference that won't be sorted out in this thread.

> If slack interactions are so unpleasant, why do you direct all support through it?

That's a whole new sentence. I was specifically referring to the support requests for Wayland, which in the long tail have been more hostile toward me than is likely warranted.

> "yes this is a hack, but we'll live with it for now until an actually good solution is available"

The hack is switching to X11, which is fully supported, or working around it in your user scripts, which has already been done by some users for their specific environment.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#203

Post by tosti » Wed, Jun 03, 2026, 5:31 AM UTC

pseudalopex wrote: post #103

Plasma/Wayland Known Significant Issues[1] No ability to save and restore positions of native Wayland windows Real-fake-session-restored apps don't remember which virtual desktop their windows were on No full-screen aspect ratio correction "Spare Layouts" feature not implemented "Per-application Keyboard Layout" does not work No way to change the gamma or manually adjust the colors without generating or finding an ap…

KDE on wayland doesn't let me roll up windows. I've been doing that for nearly 3 decades.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#204

Post by duskdozer » Wed, Jun 03, 2026, 5:32 AM UTC

Joe_Cool wrote: post #178

fhars wrote: post #106

Earlier 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 have the same issue using either an older AMD card and an RTX 3 series card. Both are fine with X11.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#205

Post by teo_zero » Wed, Jun 03, 2026, 5:47 AM UTC

foresto wrote: post #176

senfiaj wrote: post #8

What'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…

My Wayland pet peeve: It still lacks keyboard LED control, so unprivileged X11 programs that use the Scroll Lock light as an indicator cannot be ported to Wayland. This Plasma change is going to be painful for me. I wonder if there's an up-to-date list of Wayland shortcomings.

> unprivileged X11 programs that use the Scroll Lock light as an indicator

I didn't know such apps existed! What do they use it for?

Re: Preparing for KDE Plasma's Last X11-Supported Release

#206

Post by LtWorf » Wed, Jun 03, 2026, 5:48 AM UTC

Zardoz84 wrote: post #62

alyandon wrote: post #52

Earlier quoted context omitted.

I stick with LTS releases so last honest attempt would have been on a Kubuntu 24.04 LTS system. What is a compositor - thing that actually draws window content on the screen? Whatever KDE provides? Edit: To be fair to KDE/Wayland, the Wayland Kubuntu 24.04 experience was vastly improved over Kubuntu 22.04.

Just works out of the box without problems in Debian 13. The only issue that I noticed it's with screen scaling doing weird things with OpenOffice.

Out of the box for you, doesn't necessarily mean it does for everyone else.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#207

Post by tosti » Wed, Jun 03, 2026, 5:55 AM UTC

bsammon wrote: post #113

bitwize wrote: post #26

Earlier quoted context omitted.

Well, there's SonicDE, but like many such projects it's probably maintained by reactionaries which introduces its own suite of issues around security, code quality, and "will this be maintained in a year, 5 years?"

Is that "reactionaries" in the "we object to certain technology decisions" sense, like the anti-systemd crowd, or in the "software compatible with our political views" like the xlibre project? A quick search (in which I found no evidence of heated controversy) suggests to me that it's the first one.

" anti-systemd crowd "?

I suppose you're from the " hop onto the bandwagon no questions asked crowd " then.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#208

Post by tosti » Wed, Jun 03, 2026, 6:09 AM UTC

dark-star wrote: post #137

self_awareness wrote: post #127

RIP Linux Desktop

Time to switch to Windows! yay! Where all of this stuff just works: HDR, remote desktop, gaming, Picture-in-Picture, ... all the stuff that Wayland devs are too stupid to get done correctly /s (maybe?)

You forgot accessibility.

Re: Preparing for KDE Plasma's Last X11-Supported Release

#209

Post by teo_zero » Wed, Jun 03, 2026, 6:17 AM UTC

senfiaj wrote: post #8

What'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…

> doesn't allow windows to stay on top.

Are you sure that windows that, without your consent, are allowed to stay on top and grab your input are a good idea? And spawned by Chrome? As if we hadn't already enough ad-ware, click-harvesters, and spoofed dialogs popping up everywhere!

I know there is a couple of legitimate uses for this, but the ways it can be abused are vastly more.

I think the sensitive default should be to block it, and allowing it should be behind some user's conscious action. Yes, it adds some friction to some workflows and it takes a bit to get accustomed to. But it doesn't deserve the label "security paranoia".

Re: Preparing for KDE Plasma's Last X11-Supported Release

#210

Post by kelnos » Wed, Jun 03, 2026, 6:29 AM UTC

tuna74 wrote: post #96

suby wrote: post #46

I read this yesterday wanted to raise awareness for it - https://nocoffei.com/?p=451 It describes the regression in accessibility software for Linux from x11 to Wayland. Unfortunately, judging by the pace of protocols being accepted, I think we're years out from having a solution. The most notable thing not working is Talon, which is a voice input system that lets you insert speech to text, manipulate windows, call s…

"Alternatively it might make sense to build some type of bespoke solution on top of a specific wayland stack, like re implementing what you get of talon in a kde plugin or via sway IPC. This seems viable to me but an incredible amount of work." I think that is the only way forward. There is no "Linux desktop". There is KDE, Gnome etc. and if you want to do "system utilities" you have to target one of those.

No, that's a terrible idea. The right thing to do is design a Wayland protocol that gives you the access you need, get it accepted into wayland-protocols, and wait for all the compositors to implement it.

Yes, that's a slow, annoying process, but doing something bespoke means either you do the same work over and over for every compositor, or you only support one or two compositors. Neither of those is a good result.