yad: different icons under X11 and wayland

[sebo505]

Summary

yad under (GNOME) wayland seems to show a gerenic icon, and not the yad icon X11 icon: wayland icon:

Steps to reproduce

run yad in X11 run yad in wayland compare icons

Expected result

yad should run with correct icon

Actual result

yad runs with wrong icon

Environment

• [X] Is system up to date?

Repo

Shannon (stable)

Desktop Environment

GNOME

System details

Systemdetailsbericht

---

Berichtdetails

• Erstellungsdatum: 2023-11-26 13:32:25

Hardware Information:

• Hardware-Modell: Hewlett-Packard HP EliteBook 6930p
• Speicher: 8,0 GiB
• Prozessor: Intel® Core™2 Duo T9550 × 2
• Grafik: AMD RV620
• Festplattenkapazität: 500,1 GB

Software Information:

• Firmware-Version: 68PCD Ver. F.16
• Name des Betriebssystems: Solus 4.4 Harmony
• Betriebssystem-Build: (null)
• Betriebssystem-Typ: 64-bit
• GNOME-Version: 45.1
• Fenstermanager: X11
• Kernel-Version: Linux 6.5.11-263.current

Other comments

No response

[sebo505]

And speaking of yad icons: If you run several instances of yad in GNOME, GNOME dash shows as many yad icons as yad instances are running. Is this the intended behaviour? Normally, GNOME dash shows one icon per program, regardless of the number of running instances.

[ReillyBrogan]

This is an upstream issue. Solus ships the upstream desktop files without any modification. The reason this is happening is that Wayland window managers match windows to their .desktop launchers by using the desktopFileName window property. This value needs to match the name of the .desktop file without the .desktop part. The yad package ships two .desktop files, yad-icon-browser.desktop and yad-settings.desktop. However, Wayland windows started by yad have the desktopFileName property of yad, which matches neither of those files hence the missing icon.

X11 has a different behavior according to the specs. Applications are matched based on the resourceClass (also called WMClass) property. This can match either the .desktop name or the .desktop file can have the StartupWMClass property to specify an additional matcher.

I'd recommend you open this issue with the upstream yad tracker. It's something they're going to need to fix, and once they do it'll benefit all distributions using yad.