Comment 21 for bug 243390

In GNOME, the "Open With" dialog simply shows a list of applications. This list contains only .desktop files that claim to be able to open programs (which are not necessarily in the menu at all). Wine installs a shortcut named "Wine Windows Emulator" in wine.desktop, mainly for handling .exe files (my changes were primarily to solve some problems with the .exe file support, not to add support for other filetypes).

"Wine Windows Emulator" should automatically show up in your Open With dialog even though it is not in your menu. You should not have to create a shortcut for it.

I don't think KDE should be offering to open files using random menu shortcuts that do not claim to be able to open files.

The best information I was able to find so far on how the "Open With" dialog works on windows is at http://windowsxp.mvps.org/OpenWith.htm. Apparently programs install certain registry keys to let Windows know that they can open specific types of files.

For how this is handled on Linux, see http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html. Note the MimeType field. If present in a .desktop file (and only then IMO), the desktop environment should offer to open files of that type with that program, whether the .desktop file shows up in a menu or not.

> Checking if the file exists may be good for most cases. If file /p exists then
> convert if not then pass it to notepad. Next step, if file
> /home/bamm/sample.txt exists then convert to Z:\home\bamm\sample.txt otherwise
> pass it on as /home/bamm/sample.txt
This won't fly. It will break something. The easiest example for me to come up with right now is cygwin. Cygwin has its own virtual unix paths that we don't want to convert, even though it's likely in many cases that a file exists with the same name.

> Since the shortcuts have a %U% in them, then we can be sure that these
> represent files. For example, in my case I have
>
> env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft
> Office\OFFICE11\WORDVIEW.EXE" %U%
>
> the above was auto-created when wordview was installed. Maybe this string can
> be modified in such a way that Wine will recognize which of the parameters is a
> file. I have an idea but I need to work on it more.
Wine does not write shortcuts with %U% in them (and if it were to do something like that, %F would be slightly more correct). KDE probably added that to your shortcut.

That could work though. The .desktop file can be written in such a way that what it calls (which doesn't have to be wine exactly) knows that the first N arguments should be taken literally and anything after that must be a unix filename that should be converted to a windows filename. Of course, the contents of the .desktop file would probably be slightly less readable, and we'd need a command in wine that understands that.

Desktop files for start menu shortcuts are created by winemenubuilder.exe, which calls the wineshelllink script. Roughly, winemenubuilder is responsible for reading information from the .lnk and converting the icon, and wineshelllink uses the information to create the .desktop file and menu structure.