Programs are not recognized as being from different applications in a Wayland session

[allo-]

Describe the bug
When using xpra in a wayland session with KWin compositor, all xpra windows get grouped under the same taskbar entry and all windows have the xpra icon. It seems that some window class or the wayland equivalent is set to xpra and not to the window class of the forwarded program (coming from a virtual X11 server on the server-side).

To Reproduce

1. Server: xpra start :10
2. Client: xpra attach ssh://server/10 (on wayland)
3. Action: Open some windows from different applications
4. Effect: All windows are grouped as if they were from the same applications and all windows have the xpra icon, so wayland probably treats xpra windows as a single application instead of forwarded windows from different applications.

System Information (please complete the following information):

• Server OS: Debian bullseyes
• Client OS: Debian bookworm
• Xpra Server Version: v4.4.3-r0
• Xpra Client Version: v5.0-r32356

[totaam]

so wayland probably treats xpra windows as a single application instead of forwarded windows from different applications

Correct. It's a feature of wayland apparently.
We use the same API calls as we always have, they just get ignored now.
There would be a way around this issue using a subprocess for every window and then using IPC between the main network bound process and each (group of) windows based on their pid.
Needless to say, that's a huge change.

Coincidence, I've just found this which seems to imply that we can force it by re-setting it whenever it is changed:
https://github.com/linuxmint/xapp/blob/master/libxapp/xapp-gtk3-module.c
(I think that this would only work for X11)

[allo-]

I guess it may be one of the Wayland security features. But there is probably other software with similar issues (at least RDP clients) which may need or even have workarounds as well.

What does the Gtk module help, when it is only for X11? In a X11 session the windows are separate.

[totaam]

I guess it may be one of the Wayland security features

The way they claim that every broken feature is in fact a "security feature" is really getting tiresome.

which may need or even have workarounds as well

There are no known workarounds at this time.
No doubt they will change their minds once their solution needs one.

In a X11 session the windows are separate.

Correct, they haven't completely downgraded the X11 experience to the same feature subset as Wayland, not yet anyway.

[allo-]

I am a bit confused who is "they". I thought it would be a Wayland problem (possibly one of the security features). Is it an xapp/gtk problem?

[totaam]

@allo- I'd rather not start pointing fingers as this is not helpful.
Suffice to say that GTK used to be the Gimp ToolKit then at some point it became Gnome centric and now it is becoming Gnome-on-wayland centric and the features not supported by Wayland are being removed. (ie: you can no longer place windows on screen programmatically)

[allo-]

Yes, no comment on this.
I was only asking to know if this issue is pointless because it is working against a Wayland security feature or if it may be possible to fix sometime.
I think Wayland is already addressing some of the broken features by allowing for exceptions. I think I've seen, for example, a KDE screenshot with an option to allow programs to access keyboard input when other programs are focused. A setting "allow xpra to use insecure features" would probably be reasonable for future Wayland versions.

[totaam]

because it is working against a Wayland security feature or if it may be possible to fix sometime

"security" is being used as an excuse for all sorts of missing features.
This one can be worked around using a separate process, so the missing API cannot be a security feature IMO.

[allo-]

I wonder what's the cost per window of that workaround ... Currently I am still encountering strange bugs so I am using X11 at the moment, but I guess sooner or later Wayland will become the default graphics system, so one needs to deal with its restrictions.

[totaam]

I wonder what's the cost per window of that workaround ...

High. Memory usage, context switching from running as multiple processes.
With one benefit: performance, each window can use a separate CPU for decoding pixel data.

Made easier in Python 3.13 onwards thanks to PEP 734 – Multiple Interpreters in the Stdlib