You may have read about my new-found fondness for Plasma’s Clock app. Following the development of a “Picture in Picture” protocol for Wayland, I remembered how I once saw someone put up a little timer window during a lunch break while screen-sharing a presentation. I figured, I wanted that, too!
A key difference between X11 and Wayland is that Wayland is descriptive, not prescriptive. For example, a drop down menu under X11 is a window with no border that is placed in a very specific location determined by the application. It then grabs all the input so that up and down arrows work and clicking outside will dismiss it. That also means that global shortcuts won’t work while the menu is open. You can’t take a screenshot of it, you can’t even lock your screen. In 2025, this is embarrassing.
Under Wayland on the other hand, such a menu is an XDG Popup. The application tells the compositor what button it came from and what to do when it can’t fit (flip to the other side, scroll, etc). The compositor then gets to decide where to put the menu (not crossing display boundaries, for example) and to make sure it goes away when you click elsewhere or switch to a different application.
This also means that an application is a lot more restricted when it comes to – let’s say – creative window behavior. Take the picture-in-picture feature for example: an application can’t just decide to keep its window on top of everyone else. Normally, that’s a good thing! But it likewise prevents implementing a little overlay video player in your Web browser under Wayland. Enter xx-pip-v1.
It’s a protocol very similar to XDG Shell but instead of managing desktop-y windows and popups, it creates floating picture-in-picture windows. KWin recently gained support for it. As indicated by the “xx” prefix it’s an experimental protocol and therefore guarded by a KWIN_WAYLAND_SUPPORT_XX_PIP_V1 environment variable. As with most protocols, having a test case is nice but a proper application making use of it will uncover gaps and oversights in the protocol much better. Therefore, I took the opportunity to allow KClock to pop out timers and the stopwatch into a little PIP window.
While it can and does take time to sketch a Wayland protocol to realze a new use case, the end result will be generally better than anything we had before. Rather than an application deciding how PIP should behave, the compositor is in full control and subsequently you, the user. We could offer an option for which corner the window should be placed by default, or to not show it at all, and do it consistently for all applications.
Many thanks to Vlad Zahorodnii for his work on the xx-pip-v1 protocol and whose demo application the KClock implementation is based on and to David Edmundson for implementing window move/resize in the PIP window.
Screenshotting an X11 menu is easy, by using the timeout feature in a screenshot tool like Spectacle. And opening a menu in X11-Firefox, pressing CTRL-ALT-L locks the screen – seems there’s at least a way to make it work.
But I thought, that Wayland won’t do tons of stuff for specific scenarios like X11 does. And now it turns out you can’t even force a window permanently on top of the others without a specific protocol addition.
On the other hand I’m still waiting, that major Wayland implementations like KDE, GNOME and wlroots agree on the same Wayland protocol additions to do basic things like setting a keyboard layout, the display resolution or – ironically – how to make a screenshot from a third party app like Wayland-GIMP. Currently these things are missing from the standardized Wayland protocol and each Wayland implementation handles this stuff differently. A horror for third party app developers. Don’t wonder if Linux-Wayland apps lack features compared to their MS-Windows versions.
Sure there are workarounds but you can’t just press Print Screen while a menu is open like you would expect…
I’m actually glad a window can’t just decide to put itself in front. I can do that manually for any window but I don’t see a reason for an app to do that, except maybe for the PiP case for a video player.
Also, I’m glad that apps cannot change the screen resolution. That’s just awful whenever an app does that, causes your desktop icons to scramble, make the font all blurry unless you’re on a CRT etc.
And of course there’s a standard cross desktop screen short portal which an app can use to ask to take a screen shot and many apps support it.
Oh, silly apps can change the screen resolution in Wayland-KDE, Wayland-GNOME, …. They just need to use the custom mechanisms of these Wayland implementations. That’s senseless work for a decent app developer. But it’s not impossible.
Same goes for putting windows in foreground. Wayland-Firefox actually uses a silly DBus mechanism to open a file manager in foreground when clicking “open folder” in the Wayland-Firefox download window.
If apps shouldn’t do things, there should be a proper security mechanism which can be overriden by a willing user. But the Wayland situation is worse than undocumented M$-Windows-APIs. Wayland implementations are becoming more and more the nightmare M$ marketing talked about, when saying, Linux is a heavily fragmented platform. It’s not true for other aspects between Debian, Fedora, …. But Wayland implementations are really living up to that M$ statement.
Speaking for myself, I like to script complex monitor setups for my notebook. So I can quickly configure the display for reoccuring situations, in ways not offereed by the KDE or GNOME UI. But on Wayland there’s no standard protocol to do that and even googling how to do this is a hell, because the WWW is full of statements like “use wrandr”. Because people don’t know and understandibly don’t expect, that this isn’t part of the Wayland protocol.
And by the way, KDE-Plasma remembers icon positions very well for different display resolutions.
I don’t want to offend anyone. But these are real problems I’m facing as a user when trying to switch to Wayland.
P.S.
In the end, I don’t care if my system runs X11 or Wayland. But I need things to work. And for that Wayland implementations need to agree on commons standards for things beyound the current rudimentary Wayland protocol. Especially the two main players KDE and GNOME need to agree on things, so other Wayland implementations can follow.
I also need things to work. Using multiple screens with different DPI, different refresh rates, HDR, etc. None of which X11 can properly do. Using X11 on a Laptop feels like being back in 2005.