WM_CLASS and APP_ID is not set to a useful value by the program

[Botspot]

WM_CLASS should be set to something like CoBang or maybe vn.hoabinh.quan.CoBang, but right now the WM_CLASS of this app is an unhelpful __main__.py.__main__.py.

This is how you can check:

export WAYLAND_DISPLAY='' XDG_SESSION_TYPE=x11
/usr/bin/flatpak run --env=WAYLAND_DISPLAY=0 --env=XDG_SESSION_TYPE=x11 --branch=stable --arch=aarch64 --command=cobang --file-forwarding vn.hoabinh.quan.CoBang &>/dev/null &
sleep 5 #wait for it to launch
wmctrl -lx #list X11 windows and the WM_CLASS for each one

This was the full line of output from wmctrl:

0x01e00007  0 __main__.py.__main__.py  raspberrypi __main__.py

This causes some Wayland compositors to give the app a random icon, or no icon at all. Please add in the source code the customization of the window class so that the window manager can recognize the app and give it an appropriate icon.

[hongquan]

Thank you for reporting. Could you help make the change. I'm sick now and cannot work on it.

[Botspot]

Unfortunately, I am only familiar with shell scripting and cannot help you work on your codebase.

[hongquan]

Hi @Botspot It is fixed in v0.10.6 which has been released in FlatHub. Could you help test?

WM_CLASS is a X11 concept, not Wayland. The Wayland equivalent is APP_ID, which has already been set in CoBang since the first release. In my DE, GNOME, when running in X11 mode, the DE already uses APP_ID as fallback if WM_CLASS is missing, so I cannot test on my own (cannot see the difference with or without VM_CLASS). Because I focus on Wayland, I hesitate to install some pure X11 DE.

[Botspot]

Sure, I would be more than willing to help test.

Here is the output from wmctrl -lx with running CoBang with the testing command given in the first post:

0x01a00007  0 __main__.py.vn.hoabinh.quan.CoBang  raspberrypi __main__.py

Is this the value you intended to set? I was hoping that the __main__.py part would be removed completely.

On my wayland system, running CoBang normally (wayland enabled) results in an incorrect and unhelpful window name. See screenshot below. This is on Wayfire WM.

[hongquan]

It is weird that your WM is Wayland, but you managed to run CoBang as X11 app. On my system, wmctrl does not see CoBang because CoBang runs as Wayland client. wmctrl only see my other X11 apps, Slack and VS Code.

In the screenshot, you also see that the icon is chosen properly, even I use CoBang older than v0.10.6 (when I didn't know about WM_CLASS).

[Botspot]

In my first post, I tried to clarify that you can run any app as X11 by setting two environment variables.

export WAYLAND_DISPLAY='' XDG_SESSION_TYPE=x11
/usr/bin/flatpak run --env=WAYLAND_DISPLAY=0 --env=XDG_SESSION_TYPE=x11 --branch=stable --arch=aarch64 --command=cobang --file-forwarding vn.hoabinh.quan.CoBang &>/dev/null &

This forces X11 for this app on an otherwise wayland system.

[hongquan]

Thanks, I managed to run CoBang as X11 app and can see in wmtrl:

[hongquan]

Unfortunately, GTK removed the feature of setting WM_CLASS. Last time I tried set_program_class but as you can see in the screenshot above, it doesn't give expected outcome.

[Botspot]

I do not actually care about how CoBang functions on X11. I am trying to help it work better on Wayland (using the Wayfire WM) Right now, on Wayfire CoBang (with Wayland enabled) is opening with the wrong program name and with the wrong app icon.

I think that Wayland has its own way for setting APP_ID, which appears to not be working. Perhaps WM_CLASS is not the root issue. Could you find a command on Gnome to check the wayland app's APP_ID? Perhaps it is not being set as intended.

[hongquan]

I think there is no problem with CoBang on Wayland. The issue you are trying to show is the issue if you force CoBang to run as X11 app.

I tried to clarify that you can run any app as X11 by setting two environment variables.

Because DE are moving away from X11, I think the priority to make CoBang satisfy X11 is low.

I wonder why you are using a Wayland VM and you want apps to be running as X11 clients.

How about you running CoBang without forcing environment to X11:

$ flatpak run --branch=stable --arch=aarch64 --command=cobang --file-forwarding vn.hoabinh.quan.CoBang

[hongquan]

About how to check if a Wayland app set APP_ID, I don't know about other compositor, but in GNOME, you can use the "Looking Glass" tool (GNOME built-in tool, not external).

Here you can see that CoBang APP_ID is set and GNOME can determine icon for it:

-- Update 1 -- Sorry. I'm wrong. The Looking Glass screenshot doesn't tell that APP_ID is set. It only shows that GNOME has matched a desktop file with current running CoBang process. I found the command to check if APP_ID is set

$ WAYLAND_DEBUG=1 your_program

and it tells that GTK actually didn't set CoBang APP_ID as expected.

[hongquan]

Hi @Botspot I have release v.0.10.8 with the fix of setting Wayland APP_ID.

[Botspot]

I can confirm it now works. Program icon and the app name are both improved.

One small area for improvement: the app title seems to be unset, or it is being set to the same value as the APP_ID. Most apps set a useful title. For this app, I think that setting the title to "CoBang: QR scanner for Linux" would be an improvement.

[hongquan]

@Botspot v0.10.9 has been released with a fix for application title.

[Botspot]

Can confirm, it works now.