setting window class doesn't work on wayland

[c0h2r]

Contour Terminal version

0.3.1.200/0.3.12.262/0.4.0.6089

Installer source

something else (please specify below)

Operating System

Nixos unstable

Architecture

x86-64

Other Software

hyprland 0.32.0

Steps to reproduce

either set the wm_class via profiles.<profilename>. wm_class or pass it via contour class

Expected Behavior

hyprctl clients should display the new class

Actual Behavior

Nothing changes, although the result is slightly different on the old/stable and the version obtained from github actions. In the former case class is set to contour; on the git version it is simply goes blank if specified via an argument, and doesn't change when specified in the configuration.

Additional notes

Regarding the versions, the oldest one was obtained from nixpkgs (built from source), the newer versions were "repackaged" from .debs for ubuntu 22.04 (obtained from releases and github actions' artifacts).

[uspasojevic96]

Thanks for the report, however we don't have any wayland specific code, did you try with xwayland?

[christianparpart]

Wayland does not have a direct equivalent to the WM_CLASS property found in X11.

We should probably report back to the user that this value will be ignored.

Did you use XWayland or Wayland natively to spawn Contour within Hyprland?

Also, what are you trying to achieve? Maybe we'll find another way to solve this. :)

[c0h2r]

Mb it's possible to handle this situation similarly to what alacritty does? Also I'm pretty sure wezterm does smth similar since the same option works there.

Yap, running natively;

Basically I need to run an instance of contour in a scratchpad, and class is set to be able to apply windowrules to that specific window (spawn there, maximize, etc) and easily track if the hotkey should just show/hide the scratchpad or open the terminal and show it. So, another way would be to allow setting a title, I guess, or mb track the pid in the script which sounds more complicated that it should be.

[christianparpart]

Ok this is an interesting problem and related to how Qt forwards the information to the "window system".

On X11, the designated application name will be used to set the WM_CLASS, however, on Wayland, the designated application domain will be used to set the app_id.

Wayland's app_id can be used to identify and group app windows, similar to WM_CLASS on X11.

Keep in mind, that app ID on Wayland is supposed to be a domain name (e.g. contour-terminal.org) in reverse notation, so org.contour-terminal.

So if someone would like to use that to customize windowing behaviour based on that, I'd recommend to not use . in profiles.*.wm_class at all.

p.s.: it'll still require a patch to be applied, i'll drop it asap. Please test it then, and tell me if it worked for you. Is this possible?

[c0h2r]

Hm, hyprct reports the class as org.contour-terminal. no matter what class I set. Also checked in sway, and it's the same there

Maybe I'm setting it wrong?

profiles:
    someprofile:
        ...
        wm_class: "someclass"

or contour class "someclass"

[christianparpart]

hyprct reports the class as org.contour-terminal. no matter what class I set

This is interesting. I need to figure out how to get that information on Wayland myself (I'm more of an X11 user, up until now, we'll see how soon that'll change :) )

I looked into my PR and wondered. the app Id should be set (via org-domain) iff the platform name is wayland. So what is your platform name? That one I checked locally, and for me this is either xcb (X11) or wayland.

You could run contour like so: contour debug gui.display to let Contour log some GUI display information. Look for "platform name" - that one should report wayland.

I'll keep you posted if i was fast enough to figure out my brain damage. Many thanks for you patience. :)

[christianparpart]

Ok, i've found it out, I think. I used Sway and swaymsg -t get_tree to debug the introspect the app ids and the Qt's wayland source code suggested me to set the "desktopfile" property in Qt via QGuiApplication::setDesktopFileName(theWaylandAppId). This is weird indeed. I think Qt should not apply any magic here and let the Qt app devs instead chose to set the Wayland's app id explicitly (for users that want that).

[christianparpart]

@c0h2r would you mind giving the PR (latest updates) another try, please?

EDIT:

In case you did build from source, please do the following to get the latest updates (because I usually force-push within dev branches):

git remote update --prune
git reset --hard origin/fix/appid-on-wayland

All the best...

[c0h2r]

Confirmed working. Thanks!