[Bug 12380] Microsoft Word Viewer 2003: Cannot associate with *.doc files

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=12380





--- Comment #18 from Vincent Povirk <madewokherd at gmail.com>  2008-05-30 20:59:46 ---
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.


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.