GNOME Bugzilla – Bug 116129
selecting predefined web browser clears custom browser command in gnome-default-applications-properties
Last modified: 2010-12-07 16:41:02 UTC
control-center-2.2.2-1 rawhide-release-20030621-1 gnome-default-applications-properties -> preferred applications -> web browser -> custom web browser -> type something into the command -> click on "select a web browser" -> note that the command you typed was lost Suggested behaviour: The custom command should not be erased or modified regardless what is selected from "select a browser" line. ps. what would be correct component for this bug?
Triaging. This is the right component; I need to fix that sometime.
Just cuz I'm curious, what actually uses this pref. As far as i can tell most apps that need to launch a browser use gnome_vfs_url_show or its sister libgnome function. This function uses the html: scheme handler not the this pref.
The problem is that they share one GConf key, so we'd need to split the thingie: Have a custom_command, select_command and use_custom_command key. This would make the beast much more complex. regs, Chris
Reassigning preferred applications bugs into the component that, for some reason, didn't exist until now. Filter for "Andrew doing reassignment work" to get rid of this e-mail spam.
Updating version, the problem still exists. Lowering severity to enhancement.
This problem actually exists in all handler options.
Perhaps adding an additional "custom" gconf key to the URL handlers would solve this problem? This could be used to store the custom command when it is not selected.
Do we really need to preserve this in GConf, or would just keeping it in memory for the remainder of the settings "session" suffice?
Jens: It will not be possible to remember it for the rest of the session, but at least as long as the window is open. Updating version. I wonder how important this feature is, since now we have additional widgets for chosing among the most common web browser invocation variants (i.e. "Open link in new tab").
(In reply to comment #9) > It will not be possible to remember it for the rest of the session, but > at least as long as the window is open. That's what I referred to as a "settings "session"". Hence the quotation marks.
Sounds sensible. If one of the predefined items is selected when the capplet is opened, then I presume the custom exec entry should be blank (as well as insensitive).
Personally I think it ultimately would be better to store the custom entries completely separately... it would be a bit annoying if I periodically (over the course of a few days/weeks/months) switched between a predefined and a custom application, and had to re-type the custom command line every other time I opened the dialog. (Particularly if the custom command line included hard-to-remember arguments.) I appreciate the extra complexity this would add to the code, though.
I agree that it should keep the custom entry even after closing the window, but I think it's also important to show the predefined commands. I suggest that gconf should have a 'custom_command' entry that's shown in the text field only when 'Custom' is selected, otherwise the predefined command is shown in the text field.
The custom entry is gone in GNOME 3, so this won't be a problem any more. If you wish to add a new mailer, create a .desktop file which would handle the "x-scheme-handler/mailto" mime-type, and which launches your preferred mailer.