Comment 8 for bug 702452

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