KDE Plasma 6.5 released [LWN.net]

KDE Plasma 6.5 has been released. Notable new features include automatic light-to-dark theme switching based on time of day, support for the experimental Wayland picture-in-picture protocol, as well as a number of usability and accessibility improvements. See the complete changelog for a list of the new features, enhancements, and bug fixes.

to post comments

PiP protocol addition...!?

Posted Oct 22, 2025 19:43 UTC (Wed) by kolAflash (subscriber, #168136) [Link] (28 responses)

https://blog.broulik.de/2025/06/pimp-your-clock/

Damn. They said, they designed a display server protocol, which has less specific stuff in it's interface than X11. But then it turns out, that you can't even force a window on top of the others without a specific experimentatial Wayland addition.
(btw. I can take a screenshot of a menu in X11-KDE by setting a timeout in the screenshot tool and X11-GTK3 apps even allow shortcuts like ctrl-alt-L to work while a menu is opem)

On the other side, I'm still waiting for a standartized Wayland protocol addition to set basic things like keyboard layout or screen resolution. Instead there are multiple individual protocol additions handling that, different for each Wayland impelentation (KDE, GNOME, ...). Some even want you to go through DBus instead of using the Wayland socket itself to set the resolution.

And I have a very specific guess how many Wayland implementations will adapt to this new experiemental PiP Wayland API addition....

I don't say X11 is better. But Wayland is becoming more and more it's own kind of protocol hell.

PiP protocol addition...!?

Posted Oct 23, 2025 1:39 UTC (Thu) by raven667 (subscriber, #5198) [Link]

I think there is a lot of mismatch of expectations which causes unnecessary friction between fans of X11 vs Wayland (not necessarily developers of desktop environments who have a better idea of the pros/cons/tradeoffs). Wayland is a much simpler protocol which mostly concerns itself with getting pixels on screen and input to apps, all of the heavy lifting is done by compositors (desktop environments) which is how the DEs wanted it. So a window can't _make_ itself be on top, at best it can ask the window manager and the window manager (compositor) is fully in charge.

> I don't say X11 is better. But Wayland is becoming more and more it's own kind of protocol hell.

That's totally fair, for there to be more standardization the locus of effort moved from X11 as a centralizing force to the compositors/desktops and they all develop their own in-house ways of doing things, like screenshots, without sitting down and hammering out API standards. They are doing more of that now, but its slow going, it would have been nice for that work to have been front-loaded given that each DE knew they what they were implementing, but coordination is *hard*, which is why so many developers avoid it.

PiP protocol addition...!?

Posted Oct 23, 2025 2:50 UTC (Thu) by rolexhamster (guest, #158445) [Link] (1 responses)

you can't even force a window on top of the others without a specific experimentatial Wayland addition

This seems like a feature and not a bug, at least from a security perspective.

Say the window is transparent with no decorations, and proceeds to steal user input while the user is thinking that they're typing into a window underneath from a completely different app. The app controlling the transparent window could even mimic the graphical output of the app underneath.

(Disclaimer: the above is a thought experiment; I have no direct experience with Wayland other than using it as part of Gnome. In a web teleconferencing scenario, I'm very glad that sharing window contents is explicitly controlled by the user via the desktop environment, as it prevents the entire screen being shared.)

PiP protocol addition...!?

Posted Oct 23, 2025 7:16 UTC (Thu) by taladar (subscriber, #68407) [Link]

The question what applications should be allowed to do by the compositor and the question of a standardized protocol to request that thing are almost completely orthogonal though. Tightening security is no excuse for having lots of non-standard, experimental extensions only to send the request.

PiP protocol addition...!?

Posted Oct 23, 2025 4:55 UTC (Thu) by callegar (guest, #16148) [Link] (5 responses)

> But Wayland is becoming more and more it's own kind of protocol hell

Still waiting for a single cross-toolkit env variable letting one decide if apps should use wayland or X11 (xwayland).

PiP protocol addition...!?

Posted Oct 23, 2025 10:58 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

> Still waiting for a single cross-toolkit env variable letting one decide if apps should use wayland or X11 (xwayland).

Quick, without looking anything up, can you name *every* "toolkit" ever used to build *nix GUIs? Oh, and that list needs to include bespoke stuff used only by single applications.

...Now, how do you propose getting *all* of them to agree on, much less implement, anything? (Putting aside the basic assumption that said toolkits/etc are still being actively worked on?)

PiP protocol addition...!?

Posted Oct 23, 2025 12:34 UTC (Thu) by DOT (subscriber, #58786) [Link]

Plus, it seems like the choice for X11 or Wayland (or neither) is firmly on the application's side, so they will do what suits best. If you don't want to give an application access to either, just don't give access.

PiP protocol addition...!?

Posted Oct 24, 2025 8:02 UTC (Fri) by callegar (guest, #16148) [Link] (2 responses)

> Now, how do you propose getting *all* of them to agree on, much less implement, anything?

To have some XDG_something cross-toolkit variable being looked up in addition to QT_QPA_PLATFORM or GDK_BACKEND seems more a matter of coordination than a matter of implementation effort... and even if there are many toolkits, two of them are really "major" in terms of usage share, so having those two using a single agreed upon env variable could hopefully push most of the others to do the same...

This lack of coordination in minor details remains a pain point. The fact that differently to what we were used to with X11, basically every single toolkit and every single compositor can do as it wants way to often results in unpredictable results.

Things like xpra having a wayland client that is apparently unusable with plasma (because contextual menus disappear) but OK on gnome and the author honestly saying that this thing will remain unfixed as "wayland is too difficult". Or waypipe being hard to use because way to often rather than getting a window transferred to the client with waypipe, you get it to appear on the server with Xwayland. Or pinentry wrap scripts having trouble in interpreting the environment to know if it should prompt graphically or textually (so again you too easily when connecting remotely you end up with a pin entry dialog displayed graphically on the server rather than textually on the ssh session on the client).

PiP protocol addition...!?

Posted Oct 24, 2025 10:51 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> This lack of coordination in minor details remains a pain point. The fact that differently to what we were used to with X11, basically every single toolkit and every single compositor can do as it wants way to often results in unpredictable results.

Uh, how is that any different than the situation with X11 with its combinatorial explosion of extensions?

PiP protocol addition...!?

Posted Oct 24, 2025 21:59 UTC (Fri) by callegar (guest, #16148) [Link]

> Uh, how is that any different than the situation with X11 with its combinatorial explosion of extensions?

X11 was certainly not without its issues that, depending on the specific time in history oscillated between somehow bothering and really very bad. Most of the issues that I have historically encountered was with hardware support, though. I still remember the frustration with a laptop where small portions of letters on the terminal were erratically not printed due to some 2D acceleration issue. Today hardware support is generally sufficiently good, so maybe I notice other things more.

Or maybe I notice them more because the solution _seems_ easy (agreeing on a single env variable) and evidently it is not.

PiP protocol addition...!?

Posted Oct 23, 2025 15:27 UTC (Thu) by daenzer (subscriber, #7050) [Link] (15 responses)

> They said, they designed a display server protocol, which has less specific stuff in it's interface than X11.

Whoever might have said that, it sounds backwards.

Roughly speaking, X's philosophy is achieving higher-level behaviour by combining generic protocol primitives, whereas Wayland's philosophy is having dedicated protocol primitives for each specific higher-level behaviour.

The 2nd & 3rd paragraphs of the blog you linked to describe this distinction quite well.

> But then it turns out, that you can't even force a window on top of the others without a specific experimentatial Wayland addition.

FWIW, the Wayland PiP protocol isn't just about "always on top". The second-to-last paragraph of the blog you linked to goes into this.

For another example, a Wayland compositor could leave PiP windows visible in the same position even during exceptional situations like Exposé-style overviews, where windows are generally visible at different positions and sizes than normally. TTBOMK this isn't possible with X today, since the compositing manager can't distinguish between PiP windows and other "always on top" windows.

> I'm still waiting for a standartized Wayland protocol addition to set basic things like keyboard layout or screen resolution.

There's no universal consensus that those things are in scope for the Wayland protocol, so it's unlikely that they'll ever be part of Wayland protocols supported by all major compositors.

> And I have a very specific guess how many Wayland implementations will adapt to this new experiemental PiP Wayland API addition....

All the ones which care about the PiP use case, at least.

PiP protocol addition...!?

Posted Oct 23, 2025 19:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (14 responses)

> For another example, a Wayland compositor could leave PiP windows visible in the same position even during exceptional situations like Exposé-style overviews, where windows are generally visible at different positions and sizes than normally. TTBOMK this isn't possible with X today, since the compositing manager can't distinguish between PiP windows and other "always on top" windows.

One could probably do some window property settings, but then you're in the same boat as Wayland: does your window manager understand the property? Sure, a property is far simpler than a protocol, but it still need support "everywhere" to really be effective. Of interest to me: can I have, say, `mpv` use this to display on the *lock* screen while also denying/ignoring input to it? Kind of like a theater kiosk.

PiP protocol addition...!?

Posted Oct 24, 2025 7:21 UTC (Fri) by daenzer (subscriber, #7050) [Link]

> Of interest to me: can I have, say, `mpv` use this to display on the *lock* screen while also denying/ignoring input to it? Kind of like a theater kiosk.

Seems feasible in principle. The exact behaviour of PiP windows will be largely between the compositor and user.

PiP protocol addition...!?

Posted Oct 25, 2025 15:52 UTC (Sat) by raven667 (subscriber, #5198) [Link] (12 responses)

Lock screens are a funny business, I may be wrong but I think at least on GNOME the lock screen and the greeter runs on a separate VTY from any user session as their own user to keep the cred handling away from any user access at all. I would guess that's necessary to safely support fast user switching, which actually works reliably on GNOME, because on the lock screen you can legitimately log in as _someone_else_ and go to a different desktop than the one you locked in the first place. Because of that I don't think you can afford to have a regular user process interacting with the lock screen at all, that would work against the security model, but you should be able to make a simple compositor that runs a single fullscreen app and doesn't do anything else, like wayback for Xwayland, or even just some config settings in the desktop environment which supports this use case. You find similar settings on mobile devices where you can lock an app to the screen and don't allow switching away without a credential check as a parental control (hand the kid the phone to play a game but not get into your browsing history). So maybe PiP could be useful in some kiosk situation, maybe on a Smart TV, but I don't think that would be useful on the lock screen.

I'm not a desktop OS dev so I may be wrong in the details here, I'm sure more knowledgeable people will correct any glaring misconceptions.

PiP protocol addition...!?

Posted Oct 25, 2025 18:28 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> Lock screens are a funny business, I may be wrong but I think at least on GNOME the lock screen and the greeter runs on a separate VTY from any user session as their own user to keep the cred handling away from any user access at all.

Greeter yes (but that's how it works ≈everywhere), lock screen no. Lock screen is just built into the GNOME Shell, so the answer to GP's question boils down to how the Shell is implemented.

PiP protocol addition...!?

Posted Oct 27, 2025 9:40 UTC (Mon) by taladar (subscriber, #68407) [Link] (10 responses)

Logging in as as different user from a locked screen seems like an extreme niche feature in today's world where most people run their own personal devices.

PiP protocol addition...!?

Posted Oct 27, 2025 16:45 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

AFAIK, any "switch user" button kicks one out to the system-wide login manager rather than doing it directly. Not that I imagine one is *impossible*, but it seems like a lot of work for a quite niche feature with a simple workaround.

PiP protocol addition...!?

Posted Oct 28, 2025 8:22 UTC (Tue) by niner (guest, #26151) [Link] (8 responses)

If it was an "extreme niche", not every operating system would support it (ok, I don't know about Apple's). On our Android tablet me and my wife have different users because I prefer my system in English while she's more happy with German (among other reasons). On her laptop she herself has different users (with encrypted home directories) for private vs. work use because as a psychotherapist security is paramount. I have a bunch of users on my desktop because I have given access to my beefy machine to free software co-contributors who otherwise wouldn't have access to the compute power. Friends of mine have multiple users on the Windows PC attached to their TV because the kids must not have access to their full Steam library (and other things). Especially with kids I can see use for multiple accounts even on something as personal as a phone.

PiP protocol addition...!?

Posted Oct 28, 2025 9:03 UTC (Tue) by taladar (subscriber, #68407) [Link] (7 responses)

Having multiple users is one thing, allowing one to login graphically while another is still logged in with potentially system-filling numbers of applications running is what I meant about a niche feature.

PiP protocol addition...!?

Posted Oct 28, 2025 10:21 UTC (Tue) by Wol (subscriber, #4433) [Link]

> while another is still logged in with ...

Which certainly used to be the norm in my household. I'd be working away and someone else wanted the computer, so I'd just invoke the lock screen, let my stuff continue in the background, and they'd take over the computer.

But the kids have now flown the nest ...

Cheers,
Wol

PiP protocol addition...!?

Posted Oct 28, 2025 10:50 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> Allowing one to login graphically while another is still logged in with potentially system-filling numbers of applications running is what I meant about a niche feature.

It's so niche that it's been a first-class feature of Microsoft Windows (NT family) for three decades, going at least as far back as NT 4.0. (Maybe all the way back to the beginning! Corporate deployments make heavy use of this feature. (That goes for desktop Linux deployments too!)

It's so "niche" that there's probably an order of magnitude more intentional deployments of that feature than there are total Linux desktop users.

PiP protocol addition...!?

Posted Oct 28, 2025 11:08 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

But is the lock screen in Windows "just" a process running as the session user (cf. `xlock`) or is it kernel-mediated in a way that you could have some semblance of trust that you're not being keylogged when you enter your password? It is implementing it directly in the screen locker (rather than punting to the login manager) that feels niche to me.

PiP protocol addition...!?

Posted Oct 28, 2025 12:37 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

It always used to be invoked by ctrl-alt-delete.

Which is a major security feature because it explicitly triggers a hardware NMI. So there's no point implementing a "fool you" lookalike screen - for anyone who knows how it's supposed to work, you need to actively patch into the interrupt handler to hijack it.

I don't think you CAN implement it in the user's lock screen (that or the lock screen is running as root), because you need to validate the new user's password, which only root or administrator can do.

Cheers,
Wol

PiP protocol addition...!?

Posted Oct 28, 2025 14:10 UTC (Tue) by pizza (subscriber, #46) [Link]

> I don't think you CAN implement it in the user's lock screen (that or the lock screen is running as root), because you need to validate the new user's password, which only root or administrator can do.

Validating the _current_ user's password also requires root privileges.

PiP protocol addition...!?

Posted Oct 29, 2025 9:02 UTC (Wed) by taladar (subscriber, #68407) [Link]

Yes, back in the 90s and early 2000s when computers were these rare things that had to be shared a feature like that made sense. Back when university students primarily interacted with computers in rooms full of desktop computer pools.

PiP protocol addition...!?

Posted Oct 28, 2025 15:40 UTC (Tue) by geert (subscriber, #98403) [Link]

Do you really want to log out (and have to reopen all applications, and reposition all windows?) every time you stand up from your computer, and let a family member use the computer?

PiP protocol addition...!?

Posted Oct 23, 2025 18:49 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

> But then it turns out, that you can't even force a window on top of the others without a specific experimental Wayland addition.

As an end user, that's an absolute nightmare. I regularly find my work on Windows messed up by windows (some of which only ever seem to appear as a transient icon in the status bar) stealing focus.

Rule 0 of a decent GUI - don't give the user a nasty surprise! Applications forcing themselves on top of each other are prime contenders for nasty surprises. And what do you do if some idiot programmer forces their error window to the top - and in the process stops you regaining control of the computer to fix the problem?

Cheers,
Wol

PiP protocol addition...!?

Posted Oct 24, 2025 1:54 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

There are times I *want* forced-on-top or forced-focus windows: password prompts. Windows gets this right where privilege escalation prompts and the like are modal to the entire desktop session. Yes, they are quite disruptive when you're not expecting them, but my Windows usage is so limited that I think all of my cases these days are in response to explicit actions.

Contrast this with macOS where password prompts are nigh useless if some window-popping CI is in progress because new windows are "shiny" and get focus, context be damned. Good luck navigating the damned global menu or, once you do get some progress, elevating privileges to kill that rogue process if your admin password dialog can't accept a keystroke in edgewise (and you better hope that the window-popper isn't keylogging you too). In fact, it is so egregious that on machines where we missed disabling the screen lock, if CI (that you could not see…though who knows with Liquid Glass these days) was running in the background, the *lock screen* password entry would also lose focus to those windows in the background.

So yes, focus-forcing is nasty and I detest it happening (e.g., Firefox was able to force-focus itself in XMonad), but with Wayland, the compositor is in full control of such requests and can grant access to such abilities when it *does* make sense.

PiP protocol addition...!?

Posted Oct 24, 2025 8:19 UTC (Fri) by taladar (subscriber, #68407) [Link]

Password prompts are a complex example. Yes, I want them to forcefully keep the focus, but no, I don't want them to steal focus either because I might be typing something into another window and hit the wrong key at just the wrong time when it pops up and waste a password attempt at best or have some auth system cache wrong credentials or lock me out immediately at worst.

Both of those could be solved by just not allowing focus stealing at all and only allowing the user to manually switch focus to a new window.