Comment 20 for bug 243390

> KDE did not automatically give you the option to open .doc files with Word
> Viewer when you installed it, did it? If it did, that would be bad (because
> the application shortcut cannot be used to open files).

I did not understand what you mean. However, a shortcut to Word Viewer was automatically created in the menu. Double-click a DOC file, and the Open With dialog shows up. I select Word Viewer. Now I double click on DOC and the viewer opens but no file.

I can also do, from Konqueror, Settings > Configure Konqueror > File Associations and then add *.doc, and add an application to open it. A list of programs shows up. First I add OpenOffice, then I add Word Viewer.

> Judging by what you tried, it seems opening things with "Wine Windows
> Emulator" to use a separate and invisible "Wine associations" is not the
> most intuitive way to solve a problem of the form "I want to open .x files
> in program Y that I have installed in Wine."

From what I read here, I can see that I need to make a shortcut for start.exe, then select that instead. This will create more problems! Right-clicking on a doc file, selecting the Open With menu, will show "Open with start" rather than "Open with Word Viewer".

The intuitive approach is to select Microsoft Word Viewer from a list of applications. Remember that the .desktop file for Word Viewer is already automatically created by the installer. How is a user supposed to know that he should NOT select it, and that he should create a new desktop for start.exe and use that instead? This is confusing. I am not a newbie but I was confused by it. If Microsoft Word Viewer appears on the list of choices, then I would naturally select it.

> The ideal behavior would be to create a separate
> .desktop file for anything that would show up on the "Open With" list on
> Windows, for Linux's "Open With" list.

In KDE the Open With list is the same as the applications menu list. A user gets to choose from existing installed applications.

> I did a search on this topic, and apparently the "Open With" information is
> kept in the registry, completely separate from the start menu shortcuts.
> Somehow Windows gets a list of application names, extensions for each of them
> to attempt to run (which we can convert to mime types), and icons. We should
> be able to do that too.

I do not understand what you mean. I hope you can explain it more fully.

> Having Wine "correct the paths it sends to applications" is impossible.
> There's no way for Wine to determine whether what it is being given is meant
> to be a unix path (and therefore in need of conversion), windows path, or
> something completely different (say, a command line switch), and there's no
> way to determine what the application expects.

Let's say Wine receives the following command:

wine C:\WINDOWS\notepad.exe /p /home/bamm/sample.txt

and further assume that we are using native notepad instead of wine notepad. There are two arguments, a /p switch and /home/bamm/sample.txt.

The question is, which is a file and which is a switch, since both begin with a slash?

1) Idea #1

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

The only flaw would be if a file /p actually exists in the root directory. However I think it is very unlikely that a switch required by a Win32 program would have a file of the same name exist in the root directory. Only root can create files in the root directory so this would make it unlikely unless the administrator purposely created such a file.

The idea would be that if a user passed on a non-existent file as one of the arguments, it would be passed on to the program unchanged. But if an existing file is passed, as is always the case when a file is double-clicked, then do the conversion.

2) Idea #2

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.

There will be no confusion for other switches like /p because they have their own desktop files if needed, e.g., Print with Word Viewer would be

env WINEPREFIX="/home/bamm/.wine" wine "C:\Program Files\Microsoft
Office\OFFICE11\WORDVIEW.EXE" /p %U%

I'd like to know how the .desktop shortcuts are created whenever a program is installed in Wine. This will help me develop my idea more.