Bug 132509 - Open With Other Application gotchas
Summary: Open With Other Application gotchas
Alias: None
Product: Fedora
Classification: Fedora
Component: eel2   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
Depends On:
Blocks: 131589
TreeView+ depends on / blocked
Reported: 2004-09-14 08:07 UTC by Bryan W Clark
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-24 07:35:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bryan W Clark 2004-09-14 08:07:29 UTC
Just trying out a fresh install.

Thinking I could be smart and type the menu entry name since last time
the entry shows up as "gthumb" instead of the current menu entry name
"gThumb Image Viewer" that I wanted.


Right clicked on a PNG
Chose Open with Other Application...
Entered gThumb Image Viewer
Hit OK

^^ Leaves me with a 'Open With "gthumb"' entry that doesn't work

Right clicked on a PNG
Chose Open with Other Application...
Entered /usr/bin/gthumb
Hit OK

^^ Leaves me with another 'Open with "gthumb" ' entry that *does*
work, but doesn't use the actual menu name.  (isn't it supposed to?)

Now I have two .desktop files that both seem off:

[Desktop Entry]
Exec=gthumb Image Viewer

[Desktop Entry]

Comment 1 Alexander Larsson 2004-09-15 07:37:28 UTC
I don't really get what you mean by this bugreport? Are you saying we
should force users to type the full string of the name in an existing
desktop file to select that app?

I agree that we should somehow be using already existing desktop files
when selecting other applications. Probably by letting the user select
from them in a list. Although i think we should still let people enter
full pathnames, and in that case using the basename(path) for name is
the best i can think of.

Comment 2 Bryan W Clark 2004-09-15 14:59:29 UTC
No, that's not what I was suggesting.  When I tried entering the full
menu name so that the Open With %s didn't replace %s with "gthumb"
everytime and instead used "gThumb Image Viewer", the name from the
menu item.

Perhpas this is just a transition to the new MIME system problem, I'm
not sure.  However when I have an entry, call it
flux-capacitor.desktop, and I have to manually associate that entry
with a certain MIME type it seems that the association should be made
to flux-capacitor.desktop.  What it currently looks like is happening
is the creation of a flux-capacitor1.desktop and associating
mimeinfo.cache to that file instead, where flux-capacitor1.desktop has
the wrong name entry from the original flux-capacitor.desktop file.

Maybe making a list of exisiting desktop files would help in this
case, of course it also seems redundant to show this list of
applications.  There are really two cases here, either they should
have already registered the MIME type you're working with (this is a
bug against the app not registering its mime types correctly) or this
is one of those super apps like gHex that opens _every_ type of file
and just didn't associate with every MIME type since that's stupid
thing to do.  I guess redundant or not we should recognize that there
will be these bugs and that there are apps like gHex out there that we
don't want to encourage to register for everything since it's hard to
register it after the fact.

So my bug is that when registering MIME types manually to existing
apps we should at least be using the existing desktop entries if they
exist.  I'm fine with providing a list of those entries for the user
to select from along with the path entry system.  I'm assuming you're
talking about something that looks similar to the run dialog I suppose
(sans entries from the Preferences category).

Comment 3 Alexander Larsson 2004-09-15 18:57:53 UTC
Yes. I would like something like the run dialog. Of course, it should
probably have stuff thats hidden in the menu, like xdvi etc.

Comment 4 Bryan W Clark 2004-09-24 07:35:46 UTC
I guess the next move is to push this bug upstream, I'm sure there's a
bug about this already open.

Seems like these are relevant:

I should consolidate those two upstream bugs into something clear and

Note You need to log in before you can comment on or make changes to this bug.