Open Iss-in opened 2 years ago
I haven't used wayland, and I don't really have a way to easily test this and find a solution on my own. My suspicion is that they're either being picky about conventions that aren't standardized, or else their algorithm isn't smart enough because there already is an icon associated with the window. That being said, one of the other devs on the team did suggest that changing the name of the desktop file to match the app id might fix the issue. The desktop file in question is /usr/share/applications/sticky.desktop
. If you change that filename to org.x.sticky.desktop
and it works, let me know and we can look into changing it. Otherwise, I don't know what to tell you. It's impossible for me to test this in every possible configuration, or even with every possible desktop environment. I just don't have enough free time for that, but I'm open to contributions from others that fix issues in those desktops, provided that they don't break anything for the desktops we do use.
I am guessing taskbar may not be using a non standardized way to pick icons, as it is clearly using the app_id of a wayland window to pick the icon for it, which may be a wrong way but its not the primary issue here.
Issue is that the app_id of notes window is always same as name of sticky.py file. If I change the filename to sticky2.py
then that's what the app_id got changed to. which should not happen as its clearly being defined here which is totally a notes app issue imo
I dont have much experience regarding this, will try to find a fix for it :)
Please try renaming the icon /usr/share/icons/hicolor/scalable/apps/sticky.svg
to org.x.sticky.svg
.
Then run:
sudo update-icon-caches /usr/share/icons/*
Then rename the desktop file (/usr/share/applications/sticky.desktop
) to org.x.sticky.desktop
. Edit the icon line in the desktop file to be Icon=org.x.sticky
some info: https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased
this work when your gnome launcher/some app parse desktop file to get icon info. but for other type of child windows thats not the case. many other wayland compositors look for app_id to display icon. which isnt being used properly in this app
As I can see in the code,
org.x.sticky
is the application id provided to the gtk app.But if I look into window details while running app in a wayland session, app_id is
sticky.py
instead. This is causing taskbar to have no icon for app as most wayland taskbar use app_id to look for the app icon in the icon theme.on looking further, seems like app_id is always same as the name of python file, If I change the file name, app_id is also changes as such
can you please look into it