touch-packages team mailing list archive

[Bug Watch Updater <1103833@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 11 comments from the remote bug at
https://bugs.winehq.org/show_bug.cgi?id=32699.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2013-01-10T18:00:32+00:00 Simon K wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/0

------------------------------------------------------------------------
On 2013-04-13T15:33:11+00:00 Rgcjonas-c wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/4

------------------------------------------------------------------------
On 2013-05-28T12:46:57+00:00 Damjan Jovanovic wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/5

------------------------------------------------------------------------
On 2013-05-28T12:58:09+00:00 Rgcjonas-c wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/6

------------------------------------------------------------------------
On 2013-05-28T17:21:52+00:00 Vincent Povirk wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/7

------------------------------------------------------------------------
On 2013-05-28T18:24:28+00:00 Marco Trevisan (Treviño) wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/8

------------------------------------------------------------------------
On 2014-08-15T23:33:33+00:00 Michael Müller wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/18

------------------------------------------------------------------------
On 2014-11-19T19:59:39+00:00 Stu wrote:

Created attachment 50037
Low DPI icons

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/23

------------------------------------------------------------------------
On 2014-11-25T15:17:59+00:00 Marco Trevisan (Treviño) wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/24

------------------------------------------------------------------------
On 2014-12-02T20:54:46+00:00 Vincent Povirk wrote:

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.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/25

------------------------------------------------------------------------
On 2014-12-06T02:06:54+00:00 Sinister wrote:

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

Reply at:
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1103833/comments/26


** Changed in: wine
   Importance: Unknown => Wishlist

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/1103833

Title:
  Wine's icon and description appears for all Windows applications

Status in One Hundred Papercuts:
  Triaged
Status in Unity:
  Incomplete
Status in Wine:
  Unknown
Status in unity package in Ubuntu:
  Incomplete
Status in wine1.6 package in Ubuntu:
  Fix Released

Bug description:
  If I start an application using Crossover (or Wine), the application will always be the Wine Logo instead of the application logo. This is the same independent of the application being run or using Wine instead of Crossover.
  That makes sense if the application has no logo, but it gets confusing running multiple Microsoft Office programs - and all of them have the same logo.
  The hint text for the icon is also "Wine Windows Program Loader" instead of "Document 1 - Microsoft Word" as it should be.
  Unity does not seem to allow Wine/Crossover to use application icons and title text.

  I have confirmed that this issue does NOT occur in Gnome Classic, and
  is only a Unity flaw.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.10
  Package: unity 6.12.0-0ubuntu0.2
  ProcVersionSignature: Ubuntu 3.5.0-22.34-generic 3.5.7.2
  Uname: Linux 3.5.0-22-generic x86_64
  NonfreeKernelModules: fglrx
  ApportVersion: 2.6.1-0ubuntu10
  Architecture: amd64
  CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
  Date: Wed Jan 23 23:37:43 2013
  InstallationDate: Installed on 2012-10-21 (94 days ago)
  InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
  MarkForUpload: True
  SourcePackage: unity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/hundredpapercuts/+bug/1103833/+subscriptions