Comment 27 for bug 702452

I'm still (slowly) working on this. I considered putting the exe filename in StartupWMClass, but I chose to wait for the following reasons:
 * We would still have the general "Wine Windows Program Loader" launcher with its StartupWMClass of Wine. Will BAMF have any way to know that the other launchers take precedence, or will the icon that appears be essentially random? If we removed StartupWMClass from "Wine Windows Program Loader", it would break startup notification for our association.
 * We do not yet have the ability to distinguish launchers that should show up in docks (e.g. Mozilla Firefox) and "secondary" launchers that shouldn't (e.g. Mozilla Firefox (Safe Mode)). So for an application with multiple launchers, it would be random which one shows up in docks. There's a way for installers to mark shortcuts on Windows that shouldn't show up in docks, using the lnk's property store, but that feature isn't implemented yet in Wine.
 * We don't know whether the application intends to map a window from the .exe that the launcher directly starts, so we would technically be in violation of the startup notification spec. Once we have lnk property stores, we'll know this at least as well as Windows does, and we can legitimately say it's an application bug when a shortcut points to an exe that doesn't map a window, without telling us that it won't.

I don't have any way to fix point 1 short of directly telling BAMF which windows belong to which launchers (which we will have to do eventually for full compatibility with Windows, but that will take much longer than fixing points 2 and 3),