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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/702452 Title: [launcher] Wine applications are wrongly matched To manage notifications about this bug go to: https://bugs.launchpad.net/bamf/+bug/702452/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
