Re: Default browser.

[Jody Goldberg <jody gnome org>]

On Sat, Feb 14, 2004 at 12:50:44AM -0500, Luis Villa wrote:
> On Fri, 2004-02-13 at 23:54, Nat Friedman wrote:
> > On Sat, 2004-02-07 at 17:23, Frank Worsley wrote:
> > > The correct thing to use is indeed the /desktop/applications/browser key.
> > 
> > This makes sense to me, but nothing is using this key, ever, as far as I
> > can tell.
> > 
> > Right now, there is no way to change your browser in GNOME.  I think it
> > would make sense if the capplet set the key above, and applications
> > picked it up.

I disagree.  Why would we attempt to adopt key that nothing is using ?
It also contains fields (nremote) that are unused and either
shouldn't be hard coded into gnome, or should be regarded as the tip
of the iceberg of browser/mailer specific keys.

There are several different config elements coming into play

- The http handler in gnome-vfs
    gconf : /desktop/gnome/url-handlers/http/command
    This is what the preferred application capplet sets.  This
    arrangement is not idea (eg it does not set https) but it is
    currently used in gnome-vfs.  It is also does a piss poor job of
    handling argument substitution, handling only "%s".  Something
    more complex like "openurl(%s,new-window)" is not handled.  That
    is trivial to solve, but i'm not convinced it needs to be done
    in C.

- The old gnome-vfs-mime handler for text/html
    People quite rightly assume that when they set their browser the
    html handler will end up in the same place.  This is what the
    file-type capplet sets.

- The new shared-mime-data handler
    I'm adding a shim to the file type capplet to set this too.

We're mashing several very distinct use cases together here and
getting a mess.  We need to distinguish between
    - Open this url
    - Read some text/html
    - and nat's new case of 'what type of browser are you using' so
      that he can pull out the bookmarks.

If you extend the problem to include the mailer one runs into
trouble quickly because none of the mailers appear consistent about
how they handle 'mailto:'
    - mutt doesn't support mailto with no destination user
    - it's unclear how to ensure how to specify what encoding is
      used for the url string.

My preferred solution for 2.6 is
1) to add a
    /desktop/gnome/url-handlers/http/browser_type
   for nat's use and have the default application capplet set it.
2) delete the unused keys in /desktop/applications/browser
   to avoid future confusion.
3) Explicitly state that extended handling of arguments should be
   handled by external programs which are passed utf8 arguments.  I
   suppose they could be modules in 2.8, to contain meta information (eg
   the type) but that feels like over kill.  Pushing the special
   argument handling out of the core makes things like mozilla's
    -remote openurl(%s,new-tab)
   much easier to handle.  There was apparently a change in moz-1.6
   where that would fail if there are no active instances, which
   means that one needs to run with -remote, check for failure, then
   potentially run again.  That is just too much special purpose
   code for my taste given that our browser of choice is
   not-mozilla.  Distributors can easily include a shell script to
   handle it.

> I think Jody spent some time earlier this week looking at this problem
> (with his control-center hat on)- Jody? Any thoughts?

Damn, that's what I get for ignoring d-d-l for a while.
Apologies for missing the thread.