Live data from Hacker News

Preparing for KDE Plasma's Last X11-Supported Release

blog.davidedmundson.co.uk

61–70 of 392 posts

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

#61
post #2

I think the KDE developers in particular have done a great job of pushing Wayland forward and getting features that people want and need added as new protocols. KDE feels a lot smoother and more responsive when using Wayland than when using X11, and by this point most stuff has been updated to work properly on Wayland so I don't notice any breakage or missing features in day-to-day usage. > Moving forward with a sing…

> KDE feels a lot smoother and more responsive when using Wayland than when using X11 Or, the X11 code is more complex and they prefer Wayland because it is simpler. Fewer features. Is it a surprise that wayland would be faster, if it does less? > by this point most stuff has been updated to work properly on Wayland Really? Strange how comments on reddit do not confirm this. Admittedly they did fix various issues. I…

Perhaps the Wayland code path does not have to do thousands of workarounds with an ancient API made thinking on remote graphical terminals.

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

#62

Earlier quoted context omitted.

When was the last time you tried? What compositor?

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.

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

#64
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…

Strange... with Firefox in KDE/Plasma just works.

I definitely have to right click on the window in the taskbar and select Always Keep On Top with Firefox on Plasma Wayland. Not too big a deal but would be nice if it was something Firefox could just set on its own.

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

#65
post #42

Earlier quoted context omitted.

Interesting. But the only thing I would miss, is something like a settings menu. Or do you really expect me to fiddle around in config files to configure basic stuff like wifi? Or am I just stupid? Oh wait, I could use claude for that....

nmtui

Thanks for the recommendation, but "nmtui" is also the most Linux answer you could have given me :)

And it completely misses the point. Yes, there’s a lightweight tool for everything, but the appeal of KDE is that I don’t need to know. It mostly just works, is extendable and configurable.

But i also understand the appeal of staying minimal. The thing is, i want some kind of middleground: I want a simple tiling window manager. But i also want to easily install and configure stuff without falling back to the command line.

Maybe it's also brain damage of using too much Windows (with wsl). But there I have a different problem: It's easy to install and configure stuff, but it's everything else than minimal.

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

#66
post #63
post #3

How can I embed my mpv window in other application now?

qimgv uses libmpv for video playback support for example. I'm guessing that's not what you mean, but I'm struggling to think of how one might "embed" one application inside of another on xorg.

x11 supports foreign window embedding. You can embed window from other application into your own window. That's why lots of mpv/vlc based players/editors don't work probably on wayland. The only way to achieve this on wayland is writing a custom compositor for the foreign window.

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

#67
post #23

Earlier quoted context omitted.

I know nothing about the detailed technical differences between X11 and Wayland but with Hyprland for me the PIP is working as expected so I assume its not just a Wayland issue but specific to the window manager you are using? Maybe somebody else can explain?

Gnome has a "Always on Top" toggle for each window. I imagine there's a protocol for an application to set it by default but the OP's window manager might not implement it or there might be an incompatibility.

But users do not want to have to toggle that for every PiP video they watch. Its why I am still on X11

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

#68
post #30
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…

I can't speak for Chrome, but I can right click a Firefox picture-in-picture window, tell it to remain on top, and it does, no problem. I've been using Plasma Wayland for years now and this has worked for ages

The issue is you have to do that every single time. On X11, they remain on top by default

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

#69
post #16

> Moving forward with a single code path going through Wayland is going to allow us to bring new performance improvements, memory optimisations [sic], and brand new exciting features throughout Plasma. I wish they would have listed what some of those features might be.

They're still trying to figure that one out themselves.

One nice feature is trackpad gestures. x11's trackpad gestures are awful, but on Wayland you can have the 1:1 multitouch that everyone loves.

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

#70
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…

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…

Yes, exactly. This security paranoia makes the devs' lives much more complicated. I have seen many apps turning off advanced features, such as screen color pickers. Automatation tools can be broken. Apps cant know their window positions, etc. You can see countless dev rants about Wayland and how it's generally unpleasant experience to work with.
Post reply on HN