GNOME Bugzilla – Bug 163827
Can't change helper application used
Last modified: 2016-04-27 17:36:32 UTC
When opening a known file-type handled by multiple applications in Epiphany, it's only possible to open the remote file/stream with the default application. Example: - I want to play a radio stream using Totem - Click on the link, choose open: xine-ui is started (both handle the playlist mime-type used) I have no ways to knowing that: 1) Totem or xine-ui will be launched 2) Choose which of Totem or xine-ui should be launched, and the default 3) Know which mime-type or simply type the file I'm about to open is. It should be possible to: - Show the name of the file type to be opened, and which application it will be opened with - Show a list of possible helpers to use (only shown after opening with a disclosure triangle?) to show a list of possible handlers - A way to make some application the default (but the application list should always be available!)
I would like to add that an additional thing needs to be possible - it should be easy to configure which applications to use *from the browser directly*. Currently, here's how you're supposed to change the application: a) DOWNLOAD the playlist file b) OPEN it with nautilus (!!! the app that chose not to do the WEB any longer !!!) c) GO to properties d) CHANGE the default app there My grandmother calls that unintuitive, but maybe it's just her. I call it wrong, simply because a web server is in control of setting the correct mime type, and when saving a file from a web server this information does not get saved. So we're left at the mercy of nautilus to figure out this correct mime type, which it can really only get right by sheer luck in these playlist file cases. This might be a gnome-wide bug instead of epiphany specific, but how can this be solved ?
To clarify, my annoyance is more directed at myself for a) not knowing that this is the way to do it these days; b) the weird way it needs to be done and c) the embarassment because I'm just as much responsible for it being this way, since I'm a GNOME hacker; and d) the embarassment at someone asking me today the exact same thing, and having to give this answer, and making me feel like GNOME has some fundamental problems :) My frustration is in no way directed against epiphany developers, who make a fine browser that I'm still using today.
So, when "Automatically download/open", let the user choose the first time; when manually download/open, let the user choose every time? How should the info be presented? An expander with a treeview? A combo box menu?
First the easy bit, change the "You can open it with another application or save it." to "You can open it with MySuperApp or save it." so that the user knows which application would be used. An expander with a combobox and a checkbox (Which application, and whether to make it the default) would be the best to hide the rest of the grit. Alternatively, the buttons could be changed to be: [Save As...] [Open With...] [Cancel] [Open] Second solution looks best to me.
*** Bug 310566 has been marked as a duplicate of this bug. ***
I ran into this same issue tonight with my father. I would be happy to work on and submit a patch, if it would be accepted. I filed a duplicate accidentally before seeing this bug. Mozilla does this properly -- their dialog offers the option of: o Save this file to disk o Open this file with MySuperApp o Open this file with another application [Cancel] [OK] The "open with another application" option could spawn the same dialog as right clicking and saying "open with" in Nautilus. (Note that my version of Epiphany 1.7.1 already *does* show the name of the application) I think I like the radio button + OK/Cancel approach best, or the four button approach suggested by Bastien. (I will attach a mockup). Again, I will work on this and submit a patch if no one else is working on it and if the Epiphany team approves of the change.
Created attachment 49279 [details] UI Mockup Proposed UI mockup to go with my previous comment.
UI freeze, so -> 1.10
The wording and layout of the download dialog has improved with 1.8, which makes this bug a bit less severe, please test it out. It may or may not be a good idea to present a list of handlers under a disclosure widget, like the nautilus Open With menu, but this would still depend on the webserver communicating the correct MIME type.
Bastien: ping?
The dialogue now tells the application it's going to open it in. I think we could add the "Choose another application" functionality with minimal code work by using eel-mime-application-chooser (either by linking to eel [eek!] or by c'n'p'ing the code).
cut'n'paste ;)
*** Bug 326958 has been marked as a duplicate of this bug. ***
*** Bug 329549 has been marked as a duplicate of this bug. ***
Bug 155119 has a (probably bitrotted) extension that implements Open With... in the link context menu.
-> 1.12 due to feature and UI freeze.
Mass changing target 2.16 -> 2.18
Moving to 2.20 target due to feature and UI freeze for 2.18.
Moving Severity:enhancement bugs off of 2.20 target.
eel-mime-application-chooser is now in libnautilus-private/nautilus-mime-application-chooser, which depends now on GIO, so this would mean making us depend on glib trunk or use the oldest gnome-vfs code in the gnome-2-20 eel branch.
Depending on gio (glib >= 2.15.0) is fine.
I'm making a patch for this, got it almost working, but before submitting it, I'd like to know what should be the best interface for this feature. The options that have been proposed so far are: - An expander with a combobox and a checkbox (the combobox would list the applications and the checkbox would make the selected one default) - Add an "Open With..." button that pops up a nautilus-open-with-like dialog to choose the application (with the possibility to make it default for the type). - Rework the dialog to make it use checkboxes instead of buttons, and then follow an approach similar to previous option. I like the list of handlers to be presented under an expander, but kinda like the current dialog too. Could we just add an expander between the dialog secondary text and the buttons and keep just a "Open" button that opens the file with the default application or with the one selected under the expander if the user overridden it?
Maybe work with the actions that can be defined. Maybe we could have an Open with... default action?
The Open With... dialog also has an option to enter a command. Do we want/need this as well?
I suppose this use-case is handled by the 'open in containing folder' button that I gave up trying to remove last week. Bastien, still want any changes here?
Closing this bug as no further information has been provided.