[Bug 32699] New: Add StartupWMClass to .desktop files.
http://bugs.winehq.org/show_bug.cgi?id=32699 Bug #: 32699 Summary: Add StartupWMClass to .desktop files. Product: Wine Version: 1.5.21 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: Schnuff_Forum(a)web.de Classification: Unclassified 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 Simon <Schnuff_Forum(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://launchpad.net/bugs/ | |702452 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, integration Component|-unknown |programs Severity|normal |enhancement -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 Marco Trevisan (Treviño) <mail(a)3v1n0.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mail(a)3v1n0.net -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 rgcjonas(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rgcjonas(a)gmail.com --- Comment #1 from rgcjonas(a)gmail.com 2013-04-13 10:33:11 CDT --- 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 Damjan Jovanovic <damjan.jov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |damjan.jov(a)gmail.com Ever Confirmed|0 |1 --- Comment #2 from Damjan Jovanovic <damjan.jov(a)gmail.com> 2013-05-28 07:46:57 CDT --- 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 Qian Hong <fracting(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #3 from rgcjonas(a)gmail.com 2013-05-28 07:58:09 CDT --- 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #4 from Vincent Povirk <madewokherd(a)gmail.com> 2013-05-28 12:21:52 CDT --- 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #5 from Marco Trevisan (Treviño) <mail(a)3v1n0.net> 2013-05-28 13:24:28 CDT --- (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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michael(a)fds-team.de --- Comment #6 from Michael Müller <michael(a)fds-team.de> --- 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-Wind... 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Stuart Axon <stu.axon(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stu.axon(a)gmail.com --- Comment #7 from Stuart Axon <stu.axon(a)gmail.com> --- Created attachment 50037 --> https://bugs.winehq.org/attachment.cgi?id=50037 Low DPI icons Low DPI icons on internal apps, wine progman has none. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #8 from Marco Trevisan (Treviño) <mail(a)3v1n0.net> --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Jactry Zeng <jactry92(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jactry92(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #9 from Vincent Povirk <madewokherd(a)gmail.com> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Iuri Diniz <sinister(a)bol.com.br> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sinister(a)bol.com.br --- Comment #10 from Iuri Diniz <sinister(a)bol.com.br> --- 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 {} \; -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Michael Müller <michael(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/winex11-Window | |_Groups -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 josh <jake.phy(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jake.phy(a)gmail.com --- Comment #11 from josh <jake.phy(a)gmail.com> --- 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Eike Hein <hein(a)kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hein(a)kde.org --- Comment #12 from Eike Hein <hein(a)kde.org> --- 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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #13 from Eike Hein <hein(a)kde.org> --- 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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 winetest(a)luukku.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest(a)luukku.com --- Comment #14 from winetest(a)luukku.com --- (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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #15 from Eike Hein <hein(a)kde.org> --- 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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #16 from winetest(a)luukku.com --- (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/9f55292085392579568ff81b8adb926b... I am not sure what to search from there. StartupWMClass WM_CLASS Gave no results. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gijsvrm(a)gmail.com --- Comment #17 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- Was this fixed by: https://source.winehq.org/git/wine.git/commit/917e86dd7a4cca1da47262caaded2b... ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #18 from Eike Hein <hein(a)kde.org> --- I haven't had a chance to test it yet, but going by the description and diff it looks good. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 --- Comment #19 from Eike Hein <hein(a)kde.org> --- I've tested this now and I can confirm it works nicely. Thanks, this improves the experience for our users quite a bit. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|STAGED |RESOLVED Fixed by SHA1| |917e86dd7a4cca1da47262caade | |d2bef9e022f99 --- Comment #20 from Austin English <austinenglish(a)gmail.com> --- (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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=32699 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #21 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 3.4. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org