| Summary: | gnome-base/nautilus uses wrong MIME associations | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marco Lehnort <mail> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | e | ||
|
Description
Marco Lehnort
2010-11-08 15:44:17 UTC
can you reproduce this problem with other mime types ? Please also try on a new created user account and attach ~/.xsession-errors file just after reproducing the problem Created attachment 254079 [details]
e
(In reply to comment #3) > Created an attachment (id=254079) [details] > e > Argh.. somehow managed to hit return before finishing... It's the .xsession-errors of a freshly created test user, directly after logging into a gnome session for the first time and trying to open a pdf via "smb:" protocol in nautilus (which reproduced the problem, Gimp was started instead of acroread...). (In reply to comment #1) > can you reproduce this problem with other mime types ? > It does not happen with jpg (gimp), svg (gthumb), odb (open office). For those I see the same behaviour for accessing via "file:" and "smb:" protocol specifiers. However, I figured out some more: When selecting "Document Viewer" (Evince) in the Nautilus properties dialogue->open-with tab for pdf files, Evince is used in both cases. So with Evince everything seems to work ok. After changing back to the "Adobe Reader" entry, Nautilus opens pdf files as expected with Adobe Reader using "file:", but now keeps on using Evince when using "smb:" protocol! Interesting, isn't it? Think I understand now: Looks like it is acroread which is unable to open via "smb:", and Nautilus silently falls back to Evince (last one in a history of previously used applications or so?) If this is the case, I think it is not really a bug in Nautilus. It's rather a bit irritating behaviour to auto-fallback without message hinting that something went wrong. So maybe that could be improved. Maybe you could try to open that smb file passing the path directly to "acroread" command. You could also try the same with "gvfs-open" instead of "acroread" to see if some message is shown when the file is opened using evince instead of (expected) acroread (In reply to comment #6) > Maybe you could try to open that smb file passing the path directly to > "acroread" command. You could also try the same with "gvfs-open" instead of > "acroread" to see if some message is shown when the file is opened using evince > instead of (expected) acroread > Tried passing the smb path to acroread.. it simply does nothing if an instance of acroread is already running, or opens but with no document. There's no error message pointing out that the path could not be opened or is not supported. BTW: xpdf shows the same problem. With smb paths (and probably anything else than a plain path/filename) it responds with "..no such file or directory..". In Nautilus that means on smb-paths it won't open with xpdf, but with the last/some other application Nautilus knows and which is working. After all it is quite logic what's going on, but without thinking about the details the behaviour of Nautilus appears weird and broken. A little dialogue telling the user there was a problem opening file foo with application bar and asking with which application to try again would help a lot. (In reply to comment #7) > After all it is quite logic what's going on, but without thinking about the > details the behaviour of Nautilus appears weird and broken. A little dialogue > telling the user there was a problem opening file foo with application bar and > asking with which application to try again would help a lot. > If the diagnostic is correct, that should be reported directly to upstream (bugzilla.gnome.org) I think such a report would be closed wontfix. The problem is simple, the application you selected is not able to handle the URI scheme you want it to open so gvfs-open selects the next best fit. In the end, all that matters is that your file is open right ? I imagine it would also be really complicated to include in the gui a place that shows the kind of message you are proposing. Even if only informative. (In reply to comment #9) Next best fit... good point. When you want to open a PDF, would you consider it a 'fit' when Gimp is used to display it? I'd like to see that clever piece of code deciding for me how I have to view a file ;-) Why not open everything in a hex editor? After all, the file would be 'open' then... I think it's worth reporting this as an enhancement, be it difficult to do or not. This is anyway an upstream issue (bugzilla.gnome.org) Best regards |
