Comment 9 for bug 702452
Revision history for this message
| Marco Trevisan (Treviño) (3v1n0) wrote | #9 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
2eb648a
demo site
(Get the code!)
Well, as a first test (I should do this for libwnck itself, soon) I've implemented the support for WM_CLASS resource parameter in BAMF (using directly XGetClassHint) and this works as expected for this case, and so it's possible to discern each wine application as a different application, without making them being considered a wine window.
However the main issue here is matching a wine-application to its own .desktop file. In fact applications like uninstaller or winecfg have set the X hint _NET_WM_
As you'd guess, it's also very hard to associate an application window to its own .desktop file. Consider for example 7-zip.
Its wine desktop is:
[Desktop Entry]
Name=7-Zip File Manager
Exec=env WINEPREFIX=
Type=Application
StartupNotify=true
Icon=/home/
Since these desktop files calls windows' .lnk files, its quite hard for us to check if the .lnk file is loading the .exe file we're currently running. It's feasible, but it would need to parse each .lnk file to see if it could match our .exe.
In this case the desktop file name, the Name value and the .lnk file matches the application name too, but it's just a case, so I wouldn't consider them at all.
The only possible workaround would be, I guess, to use the StartupWMClass hack in the wine desktop files, setting the exe WM_CLASS file as that value, but that can't be automatized by wine itself and there's no warranty that it would lead to a desktop file clash for similar applications.
Finally, my first and simpler solution would be the one of making the wine applications just be matched via wm_class and as applications with no related .desktop file. This wouldn't allow to use them as launchers in the best way, but something could be improved hacking the .desktop file.
Any feedback?