After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 722636 - icons of wine apps are not shown in dash or in task-switcher
icons of wine apps are not shown in dash or in task-switcher
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 649087 722640 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-01-20 18:56 UTC by Asif Ali Rizvan
Modified: 2021-07-05 14:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ShellAppSystem: strip "wine-" and ".exe" from WM_CLASS before matching (1.58 KB, patch)
2014-01-20 21:08 UTC, Giovanni Campagna
rejected Details | Review
ShellWindowTracker: refuse to associate apps with wine.desktop (1.20 KB, patch)
2014-01-20 21:08 UTC, Giovanni Campagna
rejected Details | Review

Description Asif Ali Rizvan 2014-01-20 18:56:51 UTC
Icons of wine applications are not shown in dash or in alt+tab or super+tab.

How to reproduce:

1. install wine (fedora/korora: sudo yum install wine)
2. run "wine wordpad" 
3. see in the dash or press alt+tab or super+tab,
4. the icon is incorrect "wine glass" instead of "book with a small wine glass"

5. the actual application icon is visible in gnome-shell applications, to see
6. press super key or go to activities, and type wordpad, or notepad or "wine file"

Like this all other wine applications like games, etc. only wine glass is shown as wine app (may be only 'wine' is seen as the application not the executable ran from wine)

I'll check with separate script for Exec= in desktop file and update here. whether the "wine" command is responsible.
Comment 1 Asif Ali Rizvan 2014-01-20 19:04:48 UTC
update: changes Exec=script.sh with wine command in it; the speicified icon in .desktop file is not shown in dash or in alt+tab or super+tab lists.
Comment 2 Giovanni Campagna 2014-01-20 21:06:54 UTC
*** Bug 722640 has been marked as a duplicate of this bug. ***
Comment 3 Giovanni Campagna 2014-01-20 21:08:08 UTC
Created attachment 266806 [details] [review]
ShellAppSystem: strip "wine-" and ".exe" from WM_CLASS before matching

Wine programs have WM_CLASS values such as regedit.exe and wordpad.exe,
which correspond to desktop files wine-regedit.desktop and
wine-wordpad.desktop. We can get from the property to the desktop
files with a little canonicalization.
Comment 4 Giovanni Campagna 2014-01-20 21:08:18 UTC
Created attachment 266807 [details] [review]
ShellWindowTracker: refuse to associate apps with wine.desktop

wine.desktop is not a proper desktop file, because wine is not
an application in the traditional sense, so special case it in
the WM_CLASS matching and fall back to other heuristics (such
as the PID or the startup ID).
Comment 5 drago01 2014-01-24 15:43:41 UTC
Review of attachment 266806 [details] [review]:

OK.
Comment 6 drago01 2014-01-24 15:44:21 UTC
Review of attachment 266807 [details] [review]:

OK.
Comment 7 Jasper St. Pierre (not reading bugmail) 2014-01-24 15:48:44 UTC
Review of attachment 266806 [details] [review]:

ugh, no. Talk to wine upstream about fixing their WM_CLASSes. The wine- as a vendor prefix might be necessary, but I'd like to see less vendor prefixes, not more.
Comment 8 Jasper St. Pierre (not reading bugmail) 2014-01-24 15:49:31 UTC
Review of attachment 266807 [details] [review]:

Again, tell wine upstream to fix their bugs. shell-window-tracker.c is not trying to be a comprehensive workaround for app matching.
Comment 9 Giovanni Campagna 2014-01-28 20:20:18 UTC
(In reply to comment #8)
> Review of attachment 266807 [details] [review]:
> 
> Again, tell wine upstream to fix their bugs. shell-window-tracker.c is not
> trying to be a comprehensive workaround for app matching.

It should be.
We can't fix the whole world, and we should make existing apps work properly.
Comment 10 Jasper St. Pierre (not reading bugmail) 2014-01-28 21:01:16 UTC
That's what libbamf did, and it ended in disaster. The only thing we can do is try and influence app authors to obey standards.
Comment 11 drago01 2014-02-02 12:13:06 UTC
(In reply to comment #10)
> That's what libbamf did, and it ended in disaster. The only thing we can do is
> try and influence app authors to obey standards.

Both are not mutually exclusive. We can add the workaround and inform wine about the standards. But we shouldn't leave it broken like that.
Comment 12 Florian Müllner 2014-04-28 20:44:58 UTC
*** Bug 649087 has been marked as a duplicate of this bug. ***
Comment 13 Ulrich Keller 2014-11-11 08:20:10 UTC
Just FYI, here is the Wine bug report I filed about this three years ago:

https://bugs.winehq.org/show_bug.cgi?id=27032
Comment 14 GNOME Infrastructure Team 2021-07-05 14:30:18 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.