Difficult to associate a Wine application as a handler or default handler for a file type

Bug #243390 reported by Scott Ritchie on 2008-06-27
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Nautilus
Unknown
Wishlist
Wine
Fix Released
Medium
wine (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: wine

If I install Photoshop in Wine, it offers to automatically associate itself with jpeg files. This doesn't work - double clicking jpegs still opens them with the default viewer. Right clicking them also doesn't even list Photoshop as an option.

If I want to manually add Photoshop, either as the default application or something to Open With, then this too is very difficult; I have to write a script involving winepath and other complicated nonsense.

What we need is some automagical glue code that can list installed Windows applications right alongside the others. This will require generating .desktop files (with their own winepath entries inside) for every Windows application that gets installed which the user might want to open with (I believe Windows has an API for this, since there's a similar listing of applications within Windows).

To reproduce:

1) Start with a clean .wine profile just to make sure (delete .wine and run wineprefixcreate)

2) Install Microsoft Office Word Viewer 2003. Installation should succeed without problems.

3) Create a shortcut in KMenu (in KDE) or Applications menu (in Gnome). The command should look similar to this:

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

depending, of course, on the installation path you selected, and label it Microsoft Office Word Viewer 2003 (or whatever you please).

Note that this step may be unneccessary because Wine may have already created this shortcut for you.

4) Associate *.doc files (application/msword) with the Microsoft Office Word Viewer 2003.

5) Double click on a *.doc file. Word Viewer opens but the document does not open.

==

Analysis:

It seems the wrong path to the document is sent to Word Viewer. To test this, replace wordview.exe with a script that displays the full path name.

You can see this problem without actually associating *.doc files with the viewer. In my desktop you can right-click on a *.doc file, select Open With, choose Other, then browse to the shortcut you created in Step 3. The result is the same; Word Viewer opens but the document is not loaded.

(In reply to comment #0)
> Analysis:
>
> It seems the wrong path to the document is sent to Word Viewer. To test this,
> replace wordview.exe with a script that displays the full path name.

What is the wrong path being sent? Is KDE/Gnome sending the Unix path to Wine instead of the Windows path?

> What is the wrong path being sent? Is KDE/Gnome sending the Unix path to Wine
> instead of the Windows path?

Sorry for the late reply, lost access to the Internet for a few days. Yes KDE is sending the Unix path to Wine; can't test for Gnome at the moment.

Here's what I did: I whipped up a quick Visual Basic program whose only line is "MsgBox Command". This will display whatever is given as the command line parameters. I compiled it as "param.exe". I then created a Wine shortcut to param.exe, and associated *.doc files with it. After clicking on a document on the desktop, a message box popped up with the following message:

/home/bamm/Desktop/test.doc

Wine should automatically translate a Unix path to the corresponding Windows path. I was hoping to see the following result:

z:\home\bamm\Desktop\test.doc OR simply,
d:\Desktop\test.doc (since I have D: mapped to my home folder in winecfg).

Curiously, this bug only affects certain apps. Examples are Word Viewer, Excel Viewer, and IrfanView.

Powerpoint Viewer is not affected, for some reason. One can associate pptview with ppt files and the files are opened with no problem. However I do not understand how PPT Viewer got it right, since my test above shows that a random windows program like param.exe gets sent the Unix path.

Created attachment 12109
Windows executable "param.exe" that displays the command line

The attached executable param.exe was written in VB6 with only one command
MsgBox Command.

Replacing wordview.exe with this file, we can see that wordview (and other programs) receives the Unix path instead of the Windows path.

> Maybe you can try this solution:
> http://article.gmane.org/gmane.comp.emulators.wine.patches/49959

Thanks for the link. The page you gave says:

"File managers naturally use the unix path to start files, and the
wine binary passes the unix path along to the exe it starts, rather
than translating it to a windows path (this can and probably should
also be fixed somewhere else)."

I think that Wine itself should report the correct path that the applications expect. I already have a shell script that I insert in the command line to correct the path; hence it is not a problem for me. Nevertheless I reported this because it is a bug in Wine, and imho needs fixing. People should be able to associate file types directly without resorting to workarounds.

It still doesn't work.

Wine 0.9.60 gave me the impression that this has been fixed. The release notes said:

  - Better support for launching apps from Unix file managers.

Vincent Povirk (2):
      start.exe: Add /Unix switch for native file managers.
      tools: Modify wine.desktop to use start.exe /unix.

So, with the latest 0.9.61 under Kubuntu, I tried:

1) Clean Wine prefix (by deleting .wine and running wineprefixcreate)
2) Install Word Viewer (installer creates a shortcut in KMenu. Good.)
3) Associate *.doc with the .desktop file associated with Word Viewer.
4) Click on a *doc file.

Result:
Word Viewer opens but still no file loaded.

Next, I tried adding start.exe /Unix to the .desktop file's command line. That is, modifying the command line from

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

to

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

Result:
Word Viewer opens but still no file loaded.

So it looks like the solution posted didn't work.

Don't change the original reported version.

> Don't change the original reported version.

Sorry, I didn't know. :)

In , djtm (djtm) wrote :

I can confirm this bug with Microsoft Word 2003 under wine 0.9.59 and kubuntu.

My fix was to simply add a Z: in front of the path and it worked, as Z: is my root / linux directory.

I also think it should be fixed, as some part of wine should handle converting the file paths to ones that can be understood by the windows programs.

Shouldn't this be fixed by 1.0? I mean, people who install Word viewer would want the ability to associate *.doc files with it as easily as they can associate native Linux apps.

My fix was to run word viewer from a script that detects if an arg is a path (by checking if it contains a slash), and if so, replaces each / with a \ and adds a z: at the beginning, and then passes the string to wordview.exe.

Come to think of it, all apps running in Wine (not just wordview) should be run from such a script; this way user files passed on to them would be converted to a DOS-path.

> Come to think of it, all apps running in Wine (not just wordview) should be run
> from such a script; this way user files passed on to them would be converted to
> a DOS-path.

I applied a similar technique to IrfanView and now all my images can be opened in IrfanView by just double-clicking on them.

#!/bin/sh
if [ "$@" ]; then arg=z:`echo $@ | sed -e 's/\//\\\\/g'`; fi
wine "C:\Program Files\IrfanView\i_view32.exe" "$arg";

The solution being so simple (but inelegant), why can't something similar be implemented by default on all apps installed in Wine?

A more elegant solution would be to get rid of this script altogether and use Wine's built-in function for converting Unix to DOS path. (Is there such a function? I may be misinformed.)

yes, it's called winepath.

(In reply to comment #6)
> 1) Clean Wine prefix (by deleting .wine and running wineprefixcreate)

> Result:
> Word Viewer opens but still no file loaded.
>
> Next, I tried adding start.exe /Unix to the .desktop file's command line.

This is the Problem: You used a clean Wine, but the .desktop file is old
(without /unix)

> to
> env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix "C:\Program
> Files\Microsoft Office\OFFICE11\WORDVIEW.EXE" %U
>
> Result:
> Word Viewer opens but still no file loaded.

Wine is correct here.

> So it looks like the solution posted didn't work.

Remember, what parameter is a unix path, and how you modified your .desktop file

Remove the reference of WORDVIEW.EXE:

env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix %U

Problem fixed.

--
By by ... Detlef

Just to clarify, my intention (and as far as I know it now works this way) was that any file could be opened with "Wine Windows Emulator" in a shell, and it would open with whatever program is associated with that file type in Wine. It should not be necessary to create another .desktop file for Word Viewer.

> env WINEPREFIX="/home/bamm/.wine" wine start.exe /Unix %U

I'm using Kubuntu and Mandriva.

Ah, so now I see what you're at. You're solution was to associate it with START not with Word Viewer. So *.doc is still not associated with Word Viewer in Konqueror. Rather, you used the fact that *.doc is associated with Word Viewer in Explorer.

What I want, is for a user to associate extensions to programs in the /same way/ they do for normal Linux programs - that is, you can select a program from the set of existing shortcuts on the applications menu to open it in.

Also, your solution relies on the fact that the installer adds the associations to the Wine registry.

Let's take a look at my other example, IrfanView. By default IrfanView does NOT make any associations in the registry. So associating *.png with "wine start" will not help. Besides, the intuitive approach for any user is to select IrfanView from the menu, and associate it with its Desktop file.

So, I digress. I'm reopening this until Wine itself can correct the paths it sends to the application it runs.

So you're using KDE then..

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).

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." 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.

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.

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. The only thing the wine command will ever do with its argument list is pass it along unchanged to the .exe it runs.

Download full text (4.7 KiB)

> 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...

Read more...

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.

Changed in wine:
importance: Undecided → Wishlist
status: New → Confirmed
Vincent Povirk (madewokherd) wrote :

Does photoshop show up in Wine's "Open With" list on Windows? If so, this is http://bugs.winehq.org/show_bug.cgi?id=13597

I don't think it's possible to do this sensibly for apps that don't show up in "Open WIth".

Changed in wine:
status: Unknown → Confirmed
In , bobca (rcoo) wrote :

I had the very same problem, which I found also while trying to associate *.mws files with Maple V R 4 app. And the solution IS quite simple.
Clearly, launching from a shellscript
wine ~/.wine/drive_c/Program\ Files/Microsoft\ Office/OFFICE11/WORDVIEW.EXE $1
($1 being the document to open)
wouldn't work. The viewer starts but doesn't show anything.
You have to start, instead :
wine ~/.wine/drive_c/Program\ Files/Microsoft\ Office/OFFICE11/WORDVIEW.EXE "Z:"$@
THE trick is to insert "Z:" before the command-line arguments.

Now for KDE : just asssign vnd.ms-word mimetype to
wine ~/.wine/drive_c/Program\ Files/Microsoft\ Office/OFFICE11/WORDVIEW.EXE "Z:"%U

Hello

I am working on this bug. Over the past couple of days I've sent in some related patches.

Accepting, changing summary, adding integration keyword. Expect it to work by next week.

As HKEY_CLASSES_ROOT needs to merge HKEY_CURRENT_USER\Software\Classes but doesn't, this still won't work for some applications like uTorrent (#17019).

*** Bug 13597 has been marked as a duplicate of this bug. ***

Changed in wine:
status: Confirmed → Invalid
Changed in wine:
status: Invalid → Unknown
Changed in wine:
status: Unknown → In Progress
Changed in nautilus:
status: Unknown → New
Changed in wine (Ubuntu):
status: Confirmed → Triaged

Latest Git has all the needed patches for Wine's file type associations to integrate and work from freedesktop -> closing RESOLVED FIXED.

Changed in wine:
status: In Progress → Fix Released

Closing bugs fixed in 1.1.24.

Changed in nautilus:
status: New → Invalid
Changed in wine:
importance: Unknown → Medium
Changed in nautilus:
importance: Unknown → Wishlist
status: Invalid → Unknown
turbolad (turbolad995) wrote :

I was linked to this bug report by the Ubuntu Brainstorm site, in the comments:

http://brainstorm.ubuntu.com/idea/28577/

Is the issue here that shortcuts don't open (Windows) programs in Wine?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.