Linux desktop integration: Fill StartupWMClass in .desktop menu entries

Vincent Povirk madewokherd at gmail.com
Fri Apr 21 19:34:36 CDT 2017


It can be more complicated than that, but setting StartupWMClass in
that way would handle this correctly assuming:
 * A .lnk for the executable, and thus a desktop file, already exists.
 * The .lnk file points directly to the executable, and not to a shell
extension or non-executable file.
 * The executable has a unique base filename that only exists in one prefix.
 * There aren't multiple lnk files for the same executable, such as
one in the desktop and one in the start menu. (Are you able to handle
multiple matching .desktop files? This seems like it'd be a common
situation.)
 * The executable does not make use of any modern (>=win7) API's or
attributes in the .lnk file to specify the application a window
belongs to. An example of this would be an interpreter like
python.exe, for which the "application" is the python script being
executed.

So, this would be an improvement, and I see no reason it couldn't be
done, but I just want to point out that there are a lot of other cases
that Windows is able to handle, and Wine could theoretically handle
after more work and cooperation, including pinning programs for which
no shortcut exists (yet).



More information about the wine-devel mailing list