Wine's icon and description appears for all Windows applications

Bug #1103833 reported by Kevin on 2013-01-24
46
This bug affects 14 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Medium
Unassigned
Unity
Incomplete
Undecided
Unassigned
Wine
Fix Released
Wishlist
unity (Ubuntu)
Medium
Unassigned
wine1.6 (Ubuntu)
Medium
Scott Ritchie

Bug Description

If I start an application using Crossover (or Wine), the application will always be the Wine Logo instead of the application logo. This is the same independent of the application being run or using Wine instead of Crossover.
That makes sense if the application has no logo, but it gets confusing running multiple Microsoft Office programs - and all of them have the same logo.
The hint text for the icon is also "Wine Windows Program Loader" instead of "Document 1 - Microsoft Word" as it should be.
Unity does not seem to allow Wine/Crossover to use application icons and title text.

I have confirmed that this issue does NOT occur in Gnome Classic, and is only a Unity flaw.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: unity 6.12.0-0ubuntu0.2
ProcVersionSignature: Ubuntu 3.5.0-22.34-generic 3.5.7.2
Uname: Linux 3.5.0-22-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.6.1-0ubuntu10
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Wed Jan 23 23:37:43 2013
InstallationDate: Installed on 2012-10-21 (94 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

See launchpad bug here: https://bugs.launchpad.net/unity/+bug/702452

In Ubuntu Unity applications run via wine have the default wine-icon (the wine-bottle) in the "Running Program-Icons"-bar (The Task-bar).
Thus all applications are getting "stacked" under one icon.

To stop this behavior you have to write in each (generated) .desktop-file the Line:
StartupWMClass=<name of the exe-file>

Example Firefox:
StartupWMClass=firefox.exe

Wine should do this automatically after I installed my program, so the users would get the expected Icons and "Stacking-Mechanism" in Unity.

Kevin (kupiakos) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity (Ubuntu):
status: New → Confirmed

This bug is a huge usability problem nowadays (in both Gnome Shell and Unity). The current solution matches all wine applications to a single desktop file, because every wine window has a WM_CLASS of "Wine" and the desktop file a StartupWMClass=Wine . I'd consider this incorrect, because
* Every wine application is now grouped to the same .desktop file, even though they're completely different applications
* You can't start the application the window belongs to by clicking the .desktop file (<-- this is the real problem)

Furthermore, this leads to the following problems in both Unity and gnome shell:
* Every wine window is grouped to the same icon
* The description "Wine windows program launcher" doesn't help when identifying the application
* You can pin the icon to the launcher, but it will never start anything.

Luckily, windows 7 can also group and pin apps on the taskbar, and AFAIK (correct me if I'm wrong) they match windows to launchers as follows:
* If the process set a AppUserModelID for the process or the window, then windows 7 searches for a shortcut file with the matching property System.AppUserModel.ID
* In case that fails, it falls back to searching a shortcut that specifies the running exe file.
* If that doesn't work either, the 'pinning' feature is disabled for that window, and it will be grouped by the process exe file.

The only way to correctly solve our problem is by replicating windows 7's method. I'd suggest the following implementation:
* Set the StartupWMClass of every .desktop file to the System.AppUserModel.ID property of the windows shortcut (if it exists) or the (case sensitive) name of the launched .exe file.
* Let every wine window have a WM_CLASS (res_class, because gnome shell ignores res_name) of the explicit AppUserModelID, if the application has set it, or the name of the running .exe file (the value that is set to res_name as of now).

This would then show the following behaviour (which IMHO is the one the user will probably expect):
* If the application correctly set an AppUserModelID and specified it in the shortcut, the desktop will match the windows with the correct .desktop file. It will be pinnable.
* If the application displays the window from the same process that is started with the shortcut, it will also be matched (because of the .exe file name in wm_class).
* If the window does not belong to any shortcut, the desktop environment won't match it. The app will not be pinnable in that case. I don't know how Unity or Gnome Shell would handle grouping in that case.

Anything running under any runtime or custom loader (Java, Mono, Python, Perl, Ruby, even running an application with strace or gdb) will exhibit exactly the same stacking problem. Wow the Linux desktop is really owning.

The same problem microsoft was facing when they introduced windows 7. They
developed a solution (AppUserModelIDs) which maps quite cleanly to the linux
solution (WMClass). We just need to implement that AppUserModelID stuff and
export it as WM Classes.

AppUserModelID is the way to go in the long run, but it requires some missing architecture (which I've been slowly working on implementing). And to really match Windows, we'd have to generate .desktop files on demand for running programs. Of course, the .exe bit could be done without any of the new architecture.

(In reply to comment #2)
> Anything running under any runtime or custom loader (Java, Mono, Python, Perl,
> Ruby, even running an application with strace or gdb) will exhibit exactly the
> same stacking problem. Wow the Linux desktop is really owning.

That's not completely true as all these environments are generally able to be launched using an exec that matches the desktop-id or the WMClass or either to provide their WMClass. Also, at least in unity, we have a whitelist of loaders that receive a different treatment (we handle the parameter instead of the launched binary), but this is not something that can be done easily also with Wine if we want to have some basic application <-> desktop-file matching.

However, having a StartupWMClass that matches the launched .exe file (if possibile) would be enough (at least for Ubuntu unity) to properly match wine applications.

Changed in wine (Ubuntu):
status: New → Confirmed
Changed in unity (Ubuntu):
importance: Undecided → Medium
Changed in wine (Ubuntu):
importance: Undecided → Medium
Changed in unity:
status: New → Confirmed
Changed in hundredpapercuts:
importance: Undecided → Medium
status: New → Confirmed

If I start an application using Crossover (or Wine), the application will always be the Wine Logo instead of the application logo. This is the same independent of the application being run or using Wine instead of Crossover.
That makes sense if the application has no logo, but it gets confusing running multiple Microsoft Office programs - and all of them have the same logo.
The hint text for the icon is also "Wine Windows Program Loader" instead of "Document 1 - Microsoft Word" as it should be.
Unity does not seem to allow Wine/Crossover to use application icons and title text.

I have confirmed that this issue does NOT occur in Gnome Classic, and is only a Unity flaw.

Downstream report is at https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833.

Changed in wine:
importance: Undecided → Unknown
status: New → Unknown
Changed in hundredpapercuts:
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Changed in wine (Ubuntu):
status: Confirmed → Triaged

Picture of just the Wine icon appearing instead of Microsoft Word:

https://bugs.launchpad.net/wine/+bug/1103833/+attachment/3497887/+files/Untitled.png

summary: - Wine icon only appears for all Windows applications
+ Wine icon and description appears for all Windows applications
summary: - Wine icon and description appears for all Windows applications
+ Wine's icon and description appears for all Windows applications
tags: added: saucy trusty

Does it occur in regular GNOME 3 desktop?

Changed in wine:
importance: Unknown → Low
status: Unknown → New

(In reply to Alberto Salvia Novella from comment #0)

> I have confirmed that this issue does NOT occur in Gnome Classic, and is
> only a Unity flaw.
>
> Downstream report is at
> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833.

Marking upstream.

Changed in wine:
status: New → Won't Fix
Changed in wine (Ubuntu):
status: Triaged → Invalid
Frederic Defoy (fdefoy) wrote :

sweet.. another major buntu annoyance that wont get fixed /sigh

Frederic Defoy (fdefoy) wrote :

Im not sure if im reading this right but it appears both upstream and downstream is assuming this will be fixed by the other party and both marked this as fixed.

Am I reading this properly?

Christopher Townsend (townsend) wrote :

As a Unity developer who uses Crossover, I don't see this issue. The installed apps show up in the Launcher using the icon intended for the app. For example, I use Quicken Deluxe 2014 w/ Crossover and the Quicken icon is in the Launcher and when I click on it, Quicken launches and the icon shows it's launched. The tooltip for the icon also says "Quicken 2014 Deluxe".

I didn't have to do anything special for this to work either- it just worked, so I'm not really sure what is going on with other users.

@ Frederic Defoy:

The bug is marked as affecting Unity but not Wine. It is intended to be fixed in Unity only.

Scott Ritchie (scottritchie) wrote :

Christopher, could you verify if Crossover is adding StartupWMClass to the .desktop files it creates manually? As I understand it Crossover has specific installer scripts for the various applications it supports, so munging the desktop file in a way Wine doesn't generally do in order to workaround the Unity issue is totally plausible.

http://bugs.winehq.org/show_bug.cgi?id=32699

Hi,

I wrote a tiny patch which changes the window class inside of winex11 from "Wine" to the name of the program executable. This solves the problem and does not require any changes to desktop files (and it also works if you start the program from a terminal). Most window managers should now only group together the windows of the same executable and not all wine applications. The patch is available at:

https://github.com/compholio/wine-compholio/blob/master/patches/winex11-Window_Groups/0001-winex11-Prevent-window-managers-from-grouping-all-wi.patch

Could you guys verify that it works for you? I tested it with XFCE and Unity and it solves the problem.

The patch does not implement the AppUserModelIDs feature but since Wine still defaults to Windows XP mode, I assume that most applications wouldn't use this feature anyway.

Michael

Scott Ritchie (scottritchie) wrote :

There may be a workaround, a patch is posted at the linked Wine bug.

Changed in wine:
importance: Low → Unknown
status: Won't Fix → Unknown
Changed in wine (Ubuntu):
status: Invalid → Triaged
assignee: nobody → Scott Ritchie (scottritchie)

So according to the lastet comments adding a StartupWMClass corresponding to the name of the application's executable to each Wine .desktop file would be a temporary workaround for this problem, until it's fixed in Wine? Let's try it:

find "$HOME/.local/share/applications/wine/Programs" -name '*.desktop' -exec perl -pi -e 'if (m/^Exec=.+ \/Unix (.+\.lnk)/) { ($l = $1) =~ s/\\\\ / /g; $r = qx[env WINEDEBUG=-all wine shortcut /f:"$l" /a:q]; if ($r =~ m/\nTargetPath=(?:.+\\)?([^\\\n]+)/) { print "StartupWMClass=$1\n"; } }' '{}' \;

And hey, it works! Mostly, that is, for me. A few exceptions turned out to be due to to EITHER differences in capitalization between what's in the .lnk file and the actual exectutable on disk OR some internal shenanigans by program loaders/cracks.

Try this workarond at your own risk. Be sure to backup ~/.local/share/applications/wine/Programs beforehand. You may have to run "xdg-desktop-menu forceupdate" to see any changes. YMMV. To revert the changes, i.e. to remove all StartupWMClass lines from all Wine .desktop files:

find "$HOME/.local/share/applications/wine/Programs" -name '*.desktop' -exec perl -pi -e 's/StartupWMClass=.+\n//' '{}' \;

This workaround (or a permanent fix) also seems to fix https://bugs.launchpad.net/ubuntu/+source/unity/+bug/704187. And maybe https://bugs.launchpad.net/ubuntu/+source/unity/+bug/998591.

Sorry, I forgot to mention that for my workaround (see previous comment) to function you need shortcut.exe from http://optimumx.com/downloads.html#Shortcut somewhere in your Wine path (like windows/system32). This little tool "allows you to create, modify or query Windows shell links (shortcuts) from the command-line". It's been a useful addition to my Wine toolbox for so long that I forgot it's not part of Wine itself. It should be (but with a less clumsy DOSish syntax).

My apologies for the noise.

affects: wine (Ubuntu) → wine1.6 (Ubuntu)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package wine1.6 - 1:1.6.2-0ubuntu6

---------------
wine1.6 (1:1.6.2-0ubuntu6) utopic; urgency=medium

  * Remove experimental pthread patch (causes regressions)
    - http://bugs.winehq.org/show_bug.cgi?id=36772
    - http://bugs.winehq.org/show_bug.cgi?id=36744
  * Actually apply the extraneously large buffer revert patch
    - Was somehow turned off in previous update
    - Reduces audio latency; upstream only increased buffer for non-linux drivers
  * Build-depend on ocl-icd-opencl-dev instead of its deps (LP: #1371196)
    - Remove direct build-depend on ocl-icd-libopencl1 and opencl-headers
  * Add Arabic and Japanese translations for the .desktop files (LP: #1320290)
    - Thank you Akira Nakagawa
  * Remove ocl-icd-libopencl1 from recommends (LP: #1313123, #1376587)
    - Spurious as there is an automatic dependency on it or its substitutes
    - Might fix some installability problems on proprietary drivers
  * Exclude libpulse0 from auto-dependency generation (LP: #1226314)
    - It correctly remains a recommends, as it is possible to run Wine without pulseaudio
    - debian/rules: exclude winepulse.drv.so from parsing by dh_shlibdeps
  * Import patch to mostly fix wine icon appearing instead of app icon (LP: #1103833)
    - Patch courtesy Michael Müller, possibly to be replaced by later patches
  * Downgrade winbind from Recommends to Suggests (LP: #302148)
 -- Scott Ritchie <email address hidden> Mon, 06 Oct 2014 14:22:27 -0700

Changed in wine1.6 (Ubuntu):
status: Triaged → Fix Released
In , Stu (stu-axon) wrote :

Created attachment 50037
Low DPI icons

Low DPI icons on internal apps, wine progman has none.

(In reply to Michael Müller from comment #6)
> Hi,
>
> I wrote a tiny patch which changes the window class inside of winex11 from
> "Wine" to the name of the program executable. This solves the problem and
> does not require any changes to desktop files (and it also works if you
> start the program from a terminal). Most window managers should now only
> group together the windows of the same executable and not all wine
> applications. The patch is available at:

Well, while this fixes the grouping problem, this won't allow window managers to associate the actual .desktop file to the window, and thus you'd just use the embedded icon or window name, instead of the applications data defined in the .desktop file.

The default when AppUserModelID's are implemented should be the full path to the .exe file (exe's with the same filename in different directories do not group together on windows), so that's what I'd suggest setting WM_CLASS to.

I made a script in order to automate the process: https://gist.github.com/iuridiniz/85403545d0fd7e4a0000

Requisites:
Python 2.7
pyxdg
pylnk

Quick install all the requisites:
$ sudo pip install pylnk pyxdg

Quick usage:
$ python fix-wine-desktop-entry.py FILE.desktop

Quick fix all .desktop entries of a wine default installation:
$ find ~/.local/share/applications/wine -name "*.desktop" -exec python fix-wine-desktop-entry.py {} \;

Andrea Azzarone (azzar1) wrote :

Anyone using 14.10 can confirm that the bug is fixed?

Changed in unity:
status: Confirmed → Incomplete
Changed in unity (Ubuntu):
status: Triaged → Incomplete
Changed in wine:
importance: Unknown → Wishlist

Is there any news on this? The missing StartupWMClass=program.exe in the desktop files, is causing issues in my Mint Linux applet. https://github.com/jake-phy/WindowIconList/issues/105

In , Hein (sho) wrote :

I maintain the taskbar in KDE's Plasma 5. We have the same problem that Gnome Shell and Unity do. Is there any chance we can get wine to set StartupWMClass in the .desktop files it generates to the executable name it sets in WM_CLASS so we can match without unreliable hackery?

In , Hein (sho) wrote :

I've started a thread on wine-devel that goes into greater detail on this issue: https://www.winehq.org/pipermail/wine-devel/2017-April/117413.html

(In reply to Eike Hein from comment #13)
> I've started a thread on wine-devel that goes into greater detail on this
> issue: https://www.winehq.org/pipermail/wine-devel/2017-April/117413.html

Since you are so aware of the issue are you able to form a better fix? Basically anyone can contribute to wine.

In , Hein (sho) wrote :

I'm really really hoping for someone more qualified to pop up (since I don't know the wine codebase), but failing that I can try to take a stab at it yes.

(In reply to Eike Hein from comment #15)
> I'm really really hoping for someone more qualified to pop up (since I don't
> know the wine codebase), but failing that I can try to take a stab at it yes.

Does this link help?

https://source.winehq.org/git/wine.git/blob/9f55292085392579568ff81b8adb926b32a8d99a:/programs/winemenubuilder/winemenubuilder.c#l1599

I am not sure what to search from there.

StartupWMClass
WM_CLASS

Gave no results.

In , Hein (sho) wrote :

I haven't had a chance to test it yet, but going by the description and diff it looks good.

In , Hein (sho) wrote :

I've tested this now and I can confirm it works nicely. Thanks, this improves the experience for our users quite a bit.

(In reply to Eike Hein from comment #19)
> I've tested this now and I can confirm it works nicely. Thanks, this
> improves the experience for our users quite a bit.

Reported fixed (please reopen if it's not).

Changed in wine:
status: Unknown → Fix Released

Closing bugs fixed in 3.4.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.