(In reply to comment #33)
> (In reply to comment #32)
> > Perhaps we can store the Wine prefix in the .lnk file somewhere.
> You can't do that. Some dumb installers have "pre-packaged" .lnk files that are
> just copied into place.
Pre-packaged .lnk files that get just copied into place would bypass shell32's IShellLink's IPersistFile_Save, and winemenubuilder won't get invoked to build .desktop files. Such files also imply that you can't choose where to install the application, since that affects the .lnk contents?
We shouldn't store the Wine prefix in the .lnk file, it could go into some other settings database (maybe not the registry, since that's local to each Wine prefix), from where the tool that starts .lnk can look up which Wine to use.
At least we can patch Gnome and write a thumbnailer - it must be real fun and games to fix this on MacOS :-).
(In reply to comment #33)
> (In reply to comment #32)
> > Perhaps we can store the Wine prefix in the .lnk file somewhere.
> You can't do that. Some dumb installers have "pre-packaged" .lnk files that are
> just copied into place.
Pre-packaged .lnk files that get just copied into place would bypass shell32's IShellLink's IPersistFile_Save, and winemenubuilder won't get invoked to build .desktop files. Such files also imply that you can't choose where to install the application, since that affects the .lnk contents?
We shouldn't store the Wine prefix in the .lnk file, it could go into some other settings database (maybe not the registry, since that's local to each Wine prefix), from where the tool that starts .lnk can look up which Wine to use.
At least we can patch Gnome and write a thumbnailer - it must be real fun and games to fix this on MacOS :-).