[Bug 32699] Add StartupWMClass to .desktop files.

[wine-bugs at winehq.org]

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

rgcjonas at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rgcjonas at gmail.com

--- Comment #1 from rgcjonas at 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.