[launcher] Wine applications are wrongly matched

[Ugo Riboni]

After launching a Wine app from terminal or via gnome-do, it appears in the launcher with the Wine icon, instead of its own icon. The title is "Wine Window Program Loader" instead of the proper application name.
It can't be favorited since it will favorite the wine executable itself.
And obviously different wine apps are all grouped under the same launcher icon.

See also bug #635223 about Wine applications not showing up in the dash.

-----------------------------------------------------------------------------------------

A way to fix this is to make all the Wine generated .desktop file to include a StartupWMClass value that matches the instance name of the related program (generally the .exe file name to be executed).

So for example, a "Mozilla Firefox.desktop" file can be easily fixed adding this parameter:
 StartupWMClass=firefox.exe

Wine should try to add this information at file generation time.

[Florian Boucault (fboucault)]

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

[Jared (jared-vanvolkenburg)]

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?

[kkk (kknull0)]

same for me

[Id2ndR (id2ndr)]

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

[Florian Boucault (fboucault)]

The bug is still valid in Unity 2D.

[andypiper (andypiperuk)]

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.

[andypiper (andypiperuk)]

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.

[Marco Trevisan (Treviño) (3v1n0)]

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

[Marco Trevisan (Treviño) (3v1n0)]

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?

[Peter Curtis (pdcurtis)]

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

[Marco Trevisan (Treviño) (3v1n0)]

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)?

[Peter Curtis (pdcurtis)]

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.

[Peter Curtis (pdcurtis)]

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.

[Higgs Bison (bizzone)]

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.

[Scott Talbert (swt-techie)]

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

[Michael (mnichau)]

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.

[Vincent Povirk (madewokherd)]

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

[Vincent Povirk (madewokherd)]

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.

[Higgs Bison (bizzone)]

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.

[Vincent Povirk (madewokherd)]

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.

[Higgs Bison (bizzone)]

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.

[Higgs Bison (bizzone)]

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

[Higgs Bison (bizzone)]

Oops, 12.04 LTS

[Peter Curtis (pdcurtis)]

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

[Peter Curtis (pdcurtis)]

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>

[Higgs Bison (bizzone)]

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.

[Vincent Povirk (madewokherd)]

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),

[Bart Verstraete (bartverstraete)]

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!

[Ari (ari-lp)]

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

[Simon K (octav14n)]

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.

[Simon K (octav14n)]

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

[Peter Curtis (pdcurtis)]

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.

[Simon K (octav14n)]

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.

[Higgs Bison (bizzone)]

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? :)

[Rgcjonas-c (rgcjonas-c)]

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.

[Damjan Jovanovic (damjan-jov)]

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.

[Rgcjonas-c (rgcjonas-c)]

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.

[Vincent Povirk (madewokherd)]

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.

[Marco Trevisan (Treviño) (3v1n0)]

(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.

[Michael Müller (mqchael)]

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

[Stu (stu-axon)]

Created attachment 50037
Low DPI icons

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

[Marco Trevisan (Treviño) (3v1n0)]

(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.

[dobey (dobey)]

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.

[Vincent Povirk (madewokherd)]

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.

[Sinister (sinister)]

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 {} \;

[Iuri Diniz (iuridiniz)]

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

[Jake-phy (jake-phy)]

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

[Eldar Khayrullin (eldar)]

In wine-1.9.2 same bug

[Hein (sho)]

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?

[Hein (sho)]

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

[Winetest (winetest)]

(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.

[Hein (sho)]

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.

[Winetest (winetest)]

(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.

[Gijsvrm (gijsvrm)]

Was this fixed by: https://source.winehq.org/git/wine.git/commit/917e86dd7a4cca1da47262caaded2bef9e022f99 ?

[Hein (sho)]

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

[Hein (sho)]

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

[Austin English (austinenglish)]

(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).

[Alexandre Julliard (julliard)]

Closing bugs fixed in 3.4.