4.0.1 GTK wayland client has wrong wmclass

[jnsh]

What is the issue?

Under Linux/GNOME Wayland desktop, starting the 4.0.1 GTK4 client from GNOME's dash (application launcher) results in the dash not recognizing the application as transmission (not pinning it to the icon it was started from), but as a new program. If I start transmission as X11 application with GDK_BACKEND=x11 transmission-gtk there is no problem. Screenshots hopefully make the above explanation more clear:

GTK4 client started as X11 application:

GTK4 client started as wayland application:

Looking at GNOME desktop's looking glass inspector, I can see that the wmclass for the window is transmission-gtk when started in X11 mode, and com.transmissionbt.transmission_66308_1606082 as wayland application. Quick grep reveals that this is coming from gtk/Application.cc#L703.

Which application of Transmission?

GTK+ app on Linux, BSD, etc.

Which version of Transmission?

4.0.1

[Joomzie]

FWIW, this started back on 4.0. I've been building the master branch since release, and noticed this around a week ago. Didn't open an issue, though, since as you said, using GDK_BACKEND=x11 works around it.

On this note, though, do you have the option to enable the tray icon? This disappeared around the same time I noticed this problem, and I'm not sure if this is a byproduct of Wayland, or building against gtkmm-4.0. I didn't originally build against it, but after getting it installed, the option went away. It may also be possible that this was just gutted, as it seems to be GNOME's philosophy to move away from the tray.

[ckerr]

Related: https://github.com/transmission/transmission/pull/847

CC @mikedld for opinion; I'm not sure what the Right Thing is to do here

[Digitalone1]

Related: #847

CC @mikedld for opinion; I'm not sure what the Right Thing is to do here

First of all you have to set the StartupWMClass key in the desktop entry (the transmission-gtk.desktop file).

See here.

If specified, it is known that the application will map at least one window with the given string as its WM class or WM name hint (see the Startup Notification Protocol Specification for more details).

Then you have to generate a fixed wm class. I say fixed because mine is different than the one shown by @jnsh (the two IDs are different). It seems the two IDs are generated per user base?

Anyway no app does something like that. You should generate something like com.transmissionbt.transmission and then set it as the value of the StartupWMClass key inside the desktop entry.

A temporary workaround that worked for me:

1. Discover you app wmclass as @jnsh showed above.
2. Modify the transmission-gtk.desktop file with super user adding the line StartupWMClass=put_here_the_wmclass_name in the main section (put it just below StartupNotify key).

[ckerr]

Would you two like to make a PR for this?

If you two are already up-to-speed with the specs & understand what needs to change, there's probably less friction if y'all just make the PR :smile_cat:

[Digitalone1]

The PR for the desktop entry would be easy. The problem is how you set the wm class name inside the application. If you give me some hints, maybe I can do something.

[ckerr]

@mikedld ^ opinions / suggestions?

[mikedld]

IIUC there's no such thing as "wmclass" in Wayland, what they have instead is "application ID", so setting StartupWMClass in the desktop file makes little sense to me, especially because X11 backend appears to work fine without it. The Startup Notification Protocol Specification mentioned in the StartupWMClass key reference at the linked webpage explicitly talks about "X messages", not "Wayland messages" or anything else.

Looking at GTK 4 implementation, that ID on Wayland appears to be hard-wired to DBus application ID, initialized on application startup and seemingly impossible to change afterwards, and passed to top-level windows via gdk_wayland_toplevel_set_dbus_properties() within gtk_application_impl_wayland_handle_window_realize(). Our application ID (which is what GTK uses for DBus initialization) has a suffix generated based on configuration directory device ID and inode in order to prevent multiple GTK client instances using the same configuration directory but still allowing multiple GTK client instances using different configuration directories. I'll need a moment to assess if it's still something we want to have (see also #847 for another issue with it) and if there's a better way to do it (you're welcome to help). But even then, I'm still not sure what logic that GNOME panel is using to match windows with their dock icons on Wayland as there doesn't appear to be a valid explanation in comments here (correct me if I'm wrong).

FWIW, this started back on 4.0

It might be specific to building against GTK 4 rather than 3, and to whether GTK was or wasn't built with Wayland support, so not related to 4.0 per se. At least I don't see how it could be related, given that we had this setup for years.

On this note, though, do you have the option to enable the tray icon?

See #5065. Still possible to get it back when building against GTK 3 and using a shell extension.

[jnsh]

But even then, I'm still not sure what logic that GNOME panel is using to match windows with their dock icons on Wayland as there doesn't appear to be a valid explanation in comments here (correct me if I'm wrong).

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/main/src/shell-app.c#L292

If I'm not mistaken that is:

1. Application name from GIO, I believe this is where it gets transmission's DBus application ID, but didn't investigate further
2. WMCLASS in X11
3. The executable name

Also, as already mentioned, GNOME still respects the StartupWMClass in desktop files to match windows on wayland.

[Joomzie]

It might be specific to building against GTK 4 rather than 3, and to whether GTK was or wasn't built with Wayland support, so not related to 4.0 per se. At least I don't see how it could be related, given that we had this setup for years.

No, you're right. I figured this was expected behavior, but wasn't entirely sure. :)

[mattia-b89]

I see this issue in lock-screen, too

transmission-gtk-4.0.5-1
gtk4-1:4.12.4-1

[Digitalone1]

But even then, I'm still not sure what logic that GNOME panel is using to match windows with their dock icons on Wayland as there doesn't appear to be a valid explanation in comments here (correct me if I'm wrong).

There's also an open issue for Plasma Wayland. It seems more a logic related to Wayland, rather than Gnome only.

I don't know so much in details, but can't you generate a fixed ID without breaking the multiple instances mechanisms?

[v-tibi]

I know it is not a solution but renaming the "transmission-gtk.desktop" to "whatever-is-the-reported-wmclass.desktop" works as a workaround.

[X6205]

I can confirm this behaviour on Ubuntu 24.04 with Wayland. On X11 it is not a problem.

[x5f3759df]

Same here on Fedora 40