GNOME Bugzilla – Bug 757434
GNOME shell does not use windows icon
Last modified: 2019-02-27 20:30:11 UTC
Created attachment 314579 [details] GIMP run through GNOME-shell In GIMP, we have a default icon (the "Wilber" icon) set with `gtk_window_set_default_icon_name (GIMP_STOCK_WILBER)`. But we also change icons of individual windows, in particular the image windows, when they contains an image. The icon of such a window is a thumbnail of the image (for a few days, it has now been overlayed by Wilber). I realize though that when I run GIMP from the command line, it works as expected (I get the thumbnail overlayed by Wilber). But when I run GIMP from within GNOME shell (which would be the most common way of running GIMP, I guess), I get always Wilber only as icon! I am guessing that maybe when running GIMP through the shell, it uses the icon from the desktop file and discards any information from Windows? If so, I think this is a bug, and very inconsistent behavior. The icon from the Desktop file should be used for non-running software, and when a software window has not provided an icon through the desktop API. Otherwise icons provided by Windows (with gtk_window_set_icon() or equivalent) should be prioritary.
Created attachment 314580 [details] GIMP run through command line Attached the expected behavior, happening only when running GIMP through command line: as you can see, the icon is our GIMP-generated thumbnail and provided to the desktop through gtk_window_set_icon().
(In reply to Jehan from comment #1) > Attached the expected behavior No, the expected behavior is to use the application icon when referring to applications (instead of individual windows) - the dash (as most of gnome-shell) is application-based[0], so we should use an icon that is representative for the application as a whole, not a single window (what should we pick if you open *two* windows with different icons? Pick a random one? The one of the last focused window? Combine them to a new generated icon?) (In reply to Jehan from comment #0) > I realize though that when I run GIMP from the command line, it works as > expected It works as expected here, i.e. the icon from the .desktop file is used just like when launched via the Shell. This is with a distro-provided gimp though, so it's possible that more recent versions broke our window-matching heuristics when run from the terminal; if you provide the "xprop" output for the offending window in that case, we may be able to adjust the heuristics. [0] https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased
Created attachment 346414 [details] Xprop of window which does not show desktop file icon when run from command line. (In reply to Florian Müllner from comment #2) > (In reply to Jehan from comment #1) > > Attached the expected behavior > > No, the expected behavior is to use the application icon when referring to > applications (instead of individual windows) - the dash (as most of > gnome-shell) is application-based[0], so we should use an icon that is > representative for the application as a whole, not a single window (what > should we pick if you open *two* windows with different icons? Pick a random > one? The one of the last focused window? Combine them to a new generated > icon?) I understand. So gtk_window_set_icon () (and variants, gtk_window_set_icon_list (), gtk_window_set_default_icon () and gtk_window_set_default_icon_list ()) are supposed to be useless when the application is run in GNOME? These functions are useful only for Windows-based desktops? > (In reply to Jehan from comment #0) > > I realize though that when I run GIMP from the command line, it works as > > expected > > It works as expected here, i.e. the icon from the .desktop file is used just > like when launched via the Shell. This is with a distro-provided gimp > though, so it's possible that more recent versions broke our window-matching > heuristics when run from the terminal; if you provide the "xprop" output for > the offending window in that case, we may be able to adjust the heuristics. Ok well it still doesn't work here when I run it from command line. But that's indeed not a distro build (but my dev build of GIMP master), though it also has a desktop file (locally installed in ~/.local/) which works fine when run from the overview. Attached is the xprop of the window showing our custom generated icon (which is thumbnail of active image overlayed with Wilber icon).
(In reply to Jehan from comment #3) > > It works as expected here, i.e. the icon from the .desktop file is used just > > like when launched via the Shell. This is with a distro-provided gimp > > though, so it's possible that more recent versions broke our window-matching > > heuristics when run from the terminal; if you provide the "xprop" output for > > the offending window in that case, we may be able to adjust the heuristics. > > Ok well it still doesn't work here when I run it from command line. But > that's indeed not a distro build (but my dev build of GIMP master), though > it also has a desktop file (locally installed in ~/.local/) which works fine > when run from the overview. I suspect the issue here is that your build uses a WM_CLASS of gimp-2.9, but the desktop file is likely called gimp.desktop rather than gimp-2.9.desktop. When launched from the shell, we can still match the window to the .desktop file via the startup notification ID, which isn't set when started manually from the terminal. Either renaming the .desktop file to gimp-2.9.desktop or adding StartupWMClass=gimp-2.9 should fix the terminal case.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!