KDE Wayland - What's Not Working Yet

[stlnb]

@skyfishgoo

that i will not have that text to paste into my browser or terminal because kate was closed before i pasted?

Hmm, no. The application only needs to be active (and by that it means being focused) to interact with the clipboard, the clipboard is still shared.

What that ultimately means, is if you’re explicitly using a Copy/Paste button or using Ctrl+C Ctrl+V, you will be focusing the window so it will work. What it prevents is an application which tries to read or write in the clipboard programmatically (which is pretty much always being without notifying the user).

Say you copy from Kate, you’re interacting with Kate so the action is allowed → Text ends in clipboard. You want to paste the text in the browser, you right-click > paste or you focus the browser then Ctrl+V, the window is active so the action is allowed → Text which was in clipboard can be read and is pasted.

It does not affect the clipboard itself. When an item is written into it, it stays there for as long as nothing writes to it again. So that’s why @krake points at the aforementioned issue not being related to this security model.

[ddnnacheta]

This is well-explained, and I fully understand it now, I think…

However, I still don’t get how this isn’t a Wayland security feature; one that occasionally causes clipboard-related issues that only happen when using Wayland.

[stlnb]

@ddnnacheta

However, I still don’t get how this isn’t a Wayland security feature

Oh, I think that’s a misunderstanding, it is a Wayland security feature, it’s just not related to the clipboard emptying itself bug, that comes from another cause.

[krake]

@skyfishgoo

that i will not have that text to paste into my browser or terminal because kate was closed before i pasted?

No, that is what the clipboard manager is for.
It acts as the fallback “source” if the original source is no longer available.

@skyfishgoo

because i do this all day long on X11 and i need to be able to do this.

There is no change as the clipboard manager served as the fallback source here as well.

@skyfishgoo

is the middle click paste buffer also affected by wayland “security” features

No, Also, generally speaking, same setup as with X11.

[krake]

@ddnnacheta

I wouldn’t be surprised if the answer is both.

Yes, likely a combination of different factors.

There is no system level function “minimize to tray” so if an application wants to have this kind of behavior its reaction to being minimized is actually closing the window.
That makes it disappear from any task manager, window list or similar UI.
I.e. as far as the system is concerned it doesn’t have any window at all.
Hence manually closing the window resulting in the same behavior.

This most likely fails with Wayland because windows are usually not informed about their window being minimized.

Compositors can consider this an internal state and handle it in any way they see fit.
If system with taskbar might just hide the window and change the state of the taskbar entry, a system without could “roll it up” into the window decoration, or reduce it to a thumbnail or dock it somewhere.

@ddnnacheta

You quite literally just described a security feature.

I guess it could be framed as such.

@ddnnacheta

Isn’t that the reason for its implementation - security?

While client isolation is one of the design choices, it is more a bonus of having a new system rather than a reason.
Theoretically one could also introduce client isolation on X11 but most clients wouldn’t be able to cope with that.

Also, the approach of confinement is, and has been, widely used in other aspects of the operating system.
For example user’s can’t see, read or write each others’ files, they’ll need a shared location and respective access rights to do that.

Wayland just extends that to windows and by default.
X11Libre’s xnamespaces can do the same, just not enabled by default as many X11 clients expect free-for-all.

@ddnnacheta

it prevents clipboards from working the way the majority of the world is used to.

I would be surprised if the majority of users copy from or paste into a non-active window.

In every other aspect the two systems (X11 and Wayland) handle copy&paste (and drag&drop) in a very similar fashion, a data exchange between a source and destination window.
Not really surprising given that there is a large overlap in developers working on them

As @stlnb pointed out the only real difference is that on X11 any window can overwrite the current offer at any time and retrieve a posted on also at any time, while Wayland essentialy only allows either operation only for the window the user is currently interacting with.

[ddnnacheta]

@ddnnacheta

• Kwin window rules most times fail to work in Wayland sessions, but work as intended in X11.

I stand corrected! Somewhat.

Apparently, many kwin-x11 window rules and kwin/kwin-wayland window rules share the same incompatibility as kwin-x11 window rules and hyprland window rules.

What?

Basically, a window rule made when in a KDE X11 session often does not equate to the same property that KDE Wayland sessions look for to adhere to a window rule.

In other words, because I made almost all of my window rules while running a KDE X11 session, this is why most don’t work in KDE Wayland sessions.

At least now I know how to fix that issue.