Missing WM_CLASS hint breaks GNOME dash icon and grouping

[Sam]

Software

• Operating System: Ubuntu 24.04 LTS (GNOME 46.0)
• SDR++: v1.2.0 (Built at 22:59:40, May 28 2024)

Bug Description
Initialisation for GLFW backend does not include WM_CLASS hints so glfwCreateWindow() uses the title as the window class. This means GNOME doesn't map the dash icon correctly or group multiple instances under the same dash icon.

My fork has this fix:

core/backends/glfw/backend.cpp

// Set window class name (defaults to title)
glfwWindowHintString(GLFW_X11_CLASS_NAME, "sdrpp");
glfwWindowHintString(GLFW_X11_INSTANCE_NAME, "sdrpp");

sdrpp.desktop

StartupWMClass=sdrpp

Screenshots
Current nightly

Current nightly in GNOME Looking Glass

Patched

Patched in GNOME Looking Glass

Additional info
https://www.glfw.org/docs/3.3/group__window.html#ga8cb2782861c9d997bcf2dea97f363e5f
https://www.glfw.org/docs/3.3/window_guide.html#GLFW_X11_INSTANCE_NAME_hint
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

[AlexandreRouma]

I have no such issue on KDE x11 and as far as I know it's always worked properly on ubuntu previously.

Please explain how this is not a gnome issue, because the spec clearly says the WMclass is optional.
If gnome can't handle that, it's their problem.

[Sam]

I did some more digging and this happens more specifically on GNOME + Wayland, which uses app_id in the same way X11 can use WM_CLASS to match instances. The GLFW_WAYLAND_APP_ID hint was added in GLFW 3.4 glfw/glfw#2122 (comment) which isn't default on either Ubuntu 22.04 (GLFW 3.3.6) or 24.04 (GLFW 3.3.10).

Setting StartupWMClass to the GLFW window title will work but that could be unreliable given the title changes with every build. Using GLFW_X11_CLASS_NAME and GLFW_X11_INSTANCE_NAME handles the case of GLFW <3.4 on Wayland.

Ubuntu 22.04.4 LTS with GNOME 42.9 tests:

[AlexandreRouma]

Ok so this is clearly a bug with wayland not properly emulating X11 behavior or expecting special treatment from developers.

I shouldn't need to give special treatment to one specific window manager/display server when using an abstraction library like GLFW.

This is gonna be a won't fix for me.