[launcher] Wine applications are wrongly matched

The issue seemed to be fixed in Unity 2D with an up to date Natty.

I am using the latest unity build 3.8.8-0ubuntu1 on Natty 11.04 b2 and am still seeing this happen. Has it been fixed? Launching a Wine application still shows only the wine icon in the launcher and not the application icon. Is there a plan to fix it before 11.04 release if it is not yet fixed?

same for me

In my case all wine application are displayed as "Warcraft 3".

The bug is still valid in Unity 2D.

I'm seeing this as well. My example app, that I'd like to sort out, is Picasa. I've added a StartupWMClass=Wine entry to the .desktop file I'm using to launch Picasa from the Unity Launcher, but it still doesn't match the resulting running Wine app. I wonder whether the solution that Docky implemented (see bug #596092) would help here?

In the case of Picasa, it actually bundles its own Wine runtime and xprop shows WM_CLASS of "Picasa3.exe" "Wine" - and the running binary is called Picasa3.exe

Integration of Wine apps in Unity is not great at the moment and it's fairly clear that the Wine folks are unlikely to make special efforts to help on the Unity side (see e.g. http://forum.winehq.org/viewtopic.php?p=60406) so the more that can be done in Ubuntu / Unity itself, the better. Little things like icon / window / application matching for the Launcher would go a long way as a starting point.

I've succeeded in getting Picasa's window associated with the launcher icon by using StartupWMClass=Wine but unfortunately that causes *all* wine apps to be associated with the Picasa icon in the launcher.

I was just looking at this bug, and to the BAMF code related to this issue, and this is somewhat that is also related to the bug #692462 (also if here there's a little more complexity due to the fact that each .exe app needs the wine loader to be launched).

To fix correctly these bug we should basically use the same strategy: if two windows have the same tuple (WM_CLASS res, WM_CLASS name), then they belongs to the same application (of course there could be some extra checks, but basically this can be considered valid here). In fact while a chromium app window has the WM_CLASS composed by the tuple ("page_address", "Chromium-browser"), any window application has the WM_CLASS set by ("process_launched.exe", "Wine").
So, if the first value of the WM_CLASS tuple, called wm_class resource, doesn't match, then we've a different application (=> different unity icon).

This is quite easy to do from our side (except solving some dbus inconsistencies). However, the main problem is that libwnck doesn't follow the ICCCM standard [1] correctly and so it exports just the WM_CLASS class (called res_class), but it doesn't export at all the res_name, that is the thing that would make differ, for example, two wine applications, from the X property point of view! That's one of the reasons, right now, why BAMF sees two wine applications like the same app.
This libwnck issue was already reported years ago in the GNOME bugzilla (with patch), but wasn't ever applied [2].

So, now, to fix this bug I don't really know if it's the case to press the libwnck team to fix their bug, or if we should instead (waiting them) to provide a working alternative to retrieve correctly these WM_CLASS values (basically the class resource).

[1] http://tronche.com/gui/x/icccm/sec-4.html#WM_CLASS
[2] https://bugzilla.gnome.org/show_bug.cgi?id=168718

Well, as a first test (I should do this for libwnck itself, soon) I've implemented the support for WM_CLASS resource parameter in BAMF (using directly XGetClassHint) and this works as expected for this case, and so it's possible to discern each wine application as a different application, without making them being considered a wine window.

However the main issue here is matching a wine-application to its own .desktop file. In fact applications like uninstaller or winecfg have set the X hint _NET_WM_DESKTOP_FILE, which easily allow to retrieve their desktop file. But this is not possible for any other windows application.

As you'd guess, it's also very hard to associate an application window to its own .desktop file. Consider for example 7-zip.
Its wine desktop is:

[Desktop Entry]
Name=7-Zip File Manager
Exec=env WINEPREFIX="/home/marco/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/marco/.wine/dosdevices/c:/users/marco/Start\\ Menu/Programmi/7-Zip/7-Zip\\ File\\ Manager.lnk
Type=Application
StartupNotify=true
Icon=/home/marco/.local/share/icons/02c4_7zfm.0.png

Since these desktop files calls windows' .lnk files, its quite hard for us to check if the .lnk file is loading the .exe file we're currently running. It's feasible, but it would need to parse each .lnk file to see if it could match our .exe.
In this case the desktop file name, the Name value and the .lnk file matches the application name too, but it's just a case, so I wouldn't consider them at all.

The only possible workaround would be, I guess, to use the StartupWMClass hack in the wine desktop files, setting the exe WM_CLASS file as that value, but that can't be automatized by wine itself and there's no warranty that it would lead to a desktop file clash for similar applications.

Finally, my first and simpler solution would be the one of making the wine applications just be matched via wm_class and as applications with no related .desktop file. This wouldn't allow to use them as launchers in the best way, but something could be improved hacking the .desktop file.

Any feedback?

I have been working a similar problem which I put into the system as https://bugs.launchpad.net/unity/+bug/799023 - now marked as a duplicate of this bug.

I have found a workaround for the two machines I have available each with several wine applications (Dreamweaver, PaintShop, Irfanview, Notepad++ etc). The workaround is to comment out ALL the StartupWMClass=Wine lines in the .desktop files in ~/.local/share/applications which is where wine installs them in a series of subfolders.

The only exception is picasa which launches via a complex script file and in this case the picasa.desktop file has to be copied from /usr/share/applications to ~/.local/share/applications and the line StartupWMClass=Wine appended to get it to associate correctly and not show the wine icon as suggested by andypiper

A terminal command which follows should comment out all the lines starting with StartupWMClass=Wine. Copy and paste as a single long line and run from the home folder. It worked for me but I suggest backing up at least ~/.local and preferably everything first!

find $HOME/.local/share/applications -name '*.desktop' -exec sed -i 's/^StartupWMClass=Wine/#StartupWMClass=Wine/' '{}' \;

I am not sure I understand why the workaround works but hope it will give some more clues to those sorting out the problem and a short term fix for others to try. I am using a MSI Wind U100 fully with a updated 11.04, unity3d and the latest wine from the wineHQ PPA

Mh, the reason why it works is related to how BAMF uses the startupWMClass from .desktop files, however I'm wondering why no wine .desktop file in my system has that field.

What's inside yours (as example)?

Trevino, Firstly I failed to say that the changes in post 10 only come into effect after a logout and login - it seems that Unity does some matching at startup. Also .desktop files on the Desktop are not included in this 'matching' and a StartupWMClass=Wine in them have no effect when run. All of my .desktop files were created a long time ago by earlier versions of wine and all had the line - I used a command similar to the one above to find and grep for them before (and after) making the changes.

Typical files before changes were:

[Desktop Entry]
Name=Macromedia Dreamweaver MX 2004
Exec=env WINEPREFIX="/home/pcurtis/.wine" wine "C:\\Program Files\\Macromedia\\Dreamweaver MX 2004\\Dreamweaver.exe"
Type=Application
StartupWMClass=Wine
Path=/home/pcurtis/.wine/dosdevices/c:/Program Files/Macromedia/Dreamweaver MX 2004
Icon=9296_dreamweaver.0

[Desktop Entry]
Name=IrfanView 3.95
Exec=env WINEPREFIX="/home/pcurtis/.wine" wine "C:\\Program Files\\IrfanView\\i_view32.exe"
Type=Application
StartupWMClass=Wine
Icon=8ec2_i_view32.0

As you can see they are legacy applications from when I made the transition to Ubuntu with 6.06 and the .desktop files would have been created by an install by a wine version of about 3 years ago as the machine started life with 8.04.1 and I have /home on a separate partition which I preserve regardless of the type of upgrade.

A bit of extra information. Even when everything seems to work fine from the unity launcher you do not always get the correct matching if you start from a file which is associated with the program. ie if I right click on a .jpg file and open it with Paintshop Pro if turns up in the Launcher as Picasa or with a Wine Icon depending on which machine I am using.

An even more serious problem is that I tried the same with an LibreOffice .odt file and double clicking it resulted in a grey Libreoffice icon with the name LibreOffice 3.3 when you hover over it. I can not find a .desktop file on my machine which matches that in my searches so far although it opened LibreOffice Writer for the .odt file correctly. If however you pin the icon marked LibraOffice 3.3 and try to open it nothing happens. It seems the Wine problem covered in this bug may be part of a much bigger problem but I have been unable to find any overarching bug - there ought to be one against bamf or unity with a High priority as I suspect many more users will be affected by LibreOffice than Wine.

I saw that fix to libwnck was released, but how to solve this problem? Every Wine window is shown with wine default icon on unity launcher, bot not native application icon in 11.10.

In addition, duplicate window titlebar appears under Unity panel when window is maximized.

Higgs, I suspect that there is additional work that needs to be done in bamf in order to resolve this issue.

I have the same issue. The workaround I'm using is modifying the relevant desktop files in ~/.local/share/applications/wine/Programs as follows:

Original Spotify.desktop:

[Desktop Entry]
Name=Spotify
Exec=env WINEPREFIX="/home/michael/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/michael/.wine/dosdevices/c:/users/michael/Start\\ Menu/Programs/Spotify.lnk
Type=Application
StartupNotify=true
Path=/home/michael/.wine/dosdevices/c:/users/michael/Application Data/Spotify
Icon=4243_spotify.0

Modified Spotify.desktop:

[Desktop Entry]
Name=Spotify
Exec=env WINEPREFIX="/home/michael/.wine" wine "C:/users/michael/Application Data/Spotify/spotify.exe"
Categories=AudioVideo;Audio;Music;Player;
Type=Application
StartupNotify=true
StartupWMClass=spotify.exe
Path=/home/michael/.wine/dosdevices/c:/users/michael/Application Data/Spotify
Icon=4243_spotify.0

I think the important bits are:

1) passing the actual .exe file to wine instead of passing it start.exe which, in turn, is being passed the .lnk file
2) Adding "StartupWMClass=spotify.exe" to match the correct window

As a bonus, setting relevant Categories will let you filter the application correctly in the dash.

Works like a charm for me. You need to run "unity --replace" for an immediate effect the first time round, or log off and in again. I hope this helps someone.

What if Wine just told BAMF what .desktop file to use? Would that sort of thing be reasonable?

Note that Windows 7 has API's to allow processes to tell Windows which "application" each window belongs to: http://msdn.microsoft.com/en-us/library/windows/desktop/dd378459%28v=vs.85%29.aspx

To be fully correct, we'll have to implement these API's through BAMF. I haven't seen a need for this yet, but when this works better we may find corner cases where we have to do this.

Vincent Povirk (madewokherd), I think the problem is in Unity, or in Gnome environment, but not in Wine. In KDE Wine applications were properly matched.

I don't have KDE available to test. Does that apply also to Wine programs not started via .desktop files? It seems to me the goal is to match applications reliably regardless of how they are started (meaning startup notification may not be available at all), and if that problem is solved correctly then DE should not matter.

I have just checked, how icons of Wine apps are displayed in KDE taskbar. I added icon to desktop and started program. In taskbar appears correct icon of application, not default Wine glass icon. After that I tried to repeat this action in Gnome 3 shell: icon is wrong.

So I think this issue is related to Gnome environment.

In 12.10 LTS there is another nasty bug: wine icon comletely disappears wrom Unity panel after application starting.

Oops, 12.04 LTS

I have a an additional but related problem in 12.04. Even when a program displays the correct icon when you start it one can not permanently hold it in the Launcher. It will stay until one does a restart but after that it has disappeared.

The problem is only present when the launchers are in a subfolder of ~/.local/share/applications as are most wine applications which are in subfolders of ~/.local/share/applications/wine .

The workround is to copy or move them to ~/.local/share/applications

The proceedure in my posting #10 above then seems to work for all the programs I have tested.

Picasa (which is started by a script) is slightly different and needs the one to copy the picasa.desktop file from /usr/share/applications to ~/.local/share/applications and add the line StartupWMClass=Wine to the bottom of it to prevent it showing up as a Wine Launcher in the Unity Launcher - another little mystery! I added the line with a space at the begining to prevent the script in comment #10 commenting it out again.

Launchers copied to the desktop also seem to work as long as there is also a copy in ~/.local/share/applications

A bit of extra information for 12.04.

Even when everything seems to work fine from the unity launcher you do not always get the correct matching if you start from a file which is associated with the program. ie if I right click on a .jpg file and open it with Paintshop Pro if turns up in the Launcher as Picasa or with a Wine Icon depending on which machine I am using. I have tried defining a different StartupWMClass= for each program (as per #16) and placing them in~/.local/share/applications but even that still does not always give the correct behavior for starting a Wine program from an association.

It is time we got this sorted out, it is nearly a year since my last postings and nothing really seems to have changed - one can not expect new users to have to modify files and run scripts to get close to normal behavior. <End of Rant>

Is it any way to switch to wine app which is not visible on Unity panel? An issue with the disappearance of icon is very often, it`s very annoying! Only "unity --replace" helps, but not always. Please, fix this bug.

I'm still (slowly) working on this. I considered putting the exe filename in StartupWMClass, but I chose to wait for the following reasons:
 * We would still have the general "Wine Windows Program Loader" launcher with its StartupWMClass of Wine. Will BAMF have any way to know that the other launchers take precedence, or will the icon that appears be essentially random? If we removed StartupWMClass from "Wine Windows Program Loader", it would break startup notification for our association.
 * We do not yet have the ability to distinguish launchers that should show up in docks (e.g. Mozilla Firefox) and "secondary" launchers that shouldn't (e.g. Mozilla Firefox (Safe Mode)). So for an application with multiple launchers, it would be random which one shows up in docks. There's a way for installers to mark shortcuts on Windows that shouldn't show up in docks, using the lnk's property store, but that feature isn't implemented yet in Wine.
 * We don't know whether the application intends to map a window from the .exe that the launcher directly starts, so we would technically be in violation of the startup notification spec. Once we have lnk property stores, we'll know this at least as well as Windows does, and we can legitimately say it's an application bug when a shortcut points to an exe that doesn't map a window, without telling us that it won't.

I don't have any way to fix point 1 short of directly telling BAMF which windows belong to which launchers (which we will have to do eventually for full compatibility with Windows, but that will take much longer than fixing points 2 and 3),

If I append "StartupWMClass=program.exe" to the .desktop file's(where program.exe is the name of the .exe of the app) it is solved, even if I launch a file from Nautilus it works fine.
Only the icon names of the generated Office 2010 are wrong, so I have to correct them manually in the .desktop files. With other apps no problem!

This problem persists for Wine 1.53 under the altest version of PlayOnLinux. The workaround described in the OP works fine.

I added a bug to http://bugs.winehq.org.
Link: http://bugs.winehq.org/show_bug.cgi?id=32699

How can a confirmed bug affecting so many people for so long be suddenly changed in importance to Wishlist? It affects everyone using Wine and makes it near impossible for those with two Wine programs open. I would vote for Important for all using Wine.

This is a bug in Unity, not Wine. I added wine recently ( #30 )
The guys developing wine are able to produce a workaround.

The main-problem however still remains. This can only be fixed in Unity/Compiz whatever.

But since Canonical isn't about to fix theire bugs i opened the bugreport at winehq and had to link it here.

By the way, this bug, related to Unity 2d (which is not supported now) is marked as important, but this bug related to ordinary Unity shell is marked as undecided. Is there any way to report Canonical that this bug is important for Unity, too? :)

This problem is made much worse when one needs to use the "[] Emulate a virtual desktop" option in wine to make an application work; particularly when that application works using multiple different .exe files, and the setting must be enabled globally.

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

In wine-1.9.2 same bug