Update io.github.antimicrox.antimicrox.desktop with StartupWMClass=antimicrox

[Shikakiben]

hello! 🙂 Gnome dash shows generic icon if desktop file doesn't have StartupWMClass=antimicrox so if you can merge this its cool 👍

[pktiuk]

Hi @Shikakiben ,

this change seems to contradict the change from PR: https://github.com/AntiMicroX/antimicrox/pull/1100 made by @ReillyBrogan

Are you sure this would work well with Wayland? Could you provide some docs for this flag?

[ReillyBrogan]

Hi @Shikakiben ,

this change seems to contradict the change from PR: #1100 made by @ReillyBrogan

Are you sure this would work well with Wayland? Could you provide some docs for this flag?

According to the Freedesktop spec the Wayland AppId window property needs to match the .desktop file name in order for windows to be associated with the correct launcher. This behavior is implemented on all Wayland compositors to my knowledge and is the behavior I implemented by changing the AppId to match the pre-existing desktop file (note that it would have worked to have fixed it from the other side by renaming the desktop file to match the AppId, but this would have required users to repin the application to their launchers since there's no mechanism for migrating pinned applications for desktop file renames).

However because at the time many applications had incorrect associations GNOME implemented a hack so that they also match windows based on the StartupWMClass desktop property. This has honestly been a net negative for the ecosystem because many users go around updating that property and "fixing" the issue for GNOME but leaving it broken for every other Wayland environment when they could have just implemented the proper fix the first time around fixing it for everyone.

@Shikakiben isn't going to find any documentation that this property is supposed to be used on Wayland because it's not part of any Wayland-related spec. It's actually an X11-specific property that GNOME has custom Wayland handling for.

@Shikakiben are you trying to fix an issue present with antimicrox installed from a Linux distribution package or from a custom local build? If the former please open an issue with your distribution linked to this comment letting them know that they need to not rename the desktop file during packaging (because that's the only scenario where I can see this issue being present) OR they need to apply a patch to the package changing that setDesktopName() call to their renamed desktop file (though they should really just rip off the bandaid with renaming the desktop file). If a from-source build please just rename your local desktop file to io.github.antimicrox.antimicrox.desktop and after re-pinning it in your launcher it'll work just fine.

[Samueru-sama]

Hi @Shikakiben had this issue because he uses AM and we rename the .desktop to prevent conflicts with existing desktop files that the user may have already.

This is also something that appimaged and appimagelauncher do of renaming the .desktop since they use the existing $XDG_DATA_HOME/applications dir to avoid conflicts since the user may have several versions of the same app.

However because at the time many applications had incorrect associations GNOME implemented a hack so that they also match windows based on the StartupWMClass desktop property

This is not something that only gnome does, all desktop launchers use StartupWMClass to match the window class of the pinned .desktop file. And doing a qucik look at the XDG desktop spec they only mention that it should follow "reverse DNS" convention and makes no mention of window class.

The only way I see a problem with this method is if the window class is not the same on X11 and Wayland.

I think the best solution is to make sure that the window class is the same under X11 and wayland and then set StartupWMClass to that as well.

[Shikakiben]

Hello!🙂 I ask Samueru-sama to answer, because im not competent 😅, but he is, a lot! 👍

[ReillyBrogan]

This is not something that only gnome does, all desktop launchers use StartupWMClass to match the window class of the pinned .desktop file

This is true only for applications launched in an X11 session or X11 applications launched via XWayland in a Wayland session. It is absolutely not true for Wayland-native applications launched in a Wayland session because I know for a fact that Plasma does not implement this behavior.

This is fairly easily to demonstrate with Plasma if you have any Chromium-based browser installed since that has a command line flag we can use to arbitrarily set the appId:

1. Log into a Plasma Wayland session
2. Find an application where the desktop launcher has StartupWMClass set where the value does not match the name of the desktop file.
3. Run /path/to/chromium --ozone-platform-hint=auto --class=$StartupWMClass
4. Hit Meta+W to enter the overview

From here you will see that generic Wayland icon is shown over the application, indicating that kwin was not able to match the window. If you instead use the desktop name instead it will show the correct icon as specified in the desktop file indicating a successful match.

is to make sure that the window class is the same under X11 and wayland

It is already the same because QGuiApplication::setDesktopFileName() sets the appId if the Qt application is running through the Wayland platform plugin and the window class if running through the XCB platform plugin.

[Samueru-sama]

Alright I just booted into a wayland session with kde, tested with CItron because this AppImage does have a working wayland and has StartupWMClass set:

Everything is fine

If I remove StartupWMClass then my panel breaks and the icon duplicates:

I also wanted to test Antimicrox but I get this error and the window and the popup window is using xwayland:

[Samueru-sama]

1. Log into a Plasma Wayland session

2. Find an application where the desktop launcher has `StartupWMClass` set where the value does not match the name of the desktop file.

3. Run `/path/to/chromium --ozone-platform-hint=auto --class=$StartupWMClass`

4. Hit `Meta+W` to enter the overview

From here you will see that generic Wayland icon is shown over the application, indicating that kwin was not able to match the window. If you instead use the desktop name instead it will show the correct icon as specified in the desktop file indicating a successful match.

Like this?

I don't see any generic wayland icon.

Had to use --no-sandbox to fix an unrelated issue btw.