Re: GLib plans for the next cycle

[Alexander Larsson <alexl redhat com>]

On Tue, 2009-04-21 at 11:38 -0700, Brian J. Tarricone wrote:
> Alexander Larsson wrote:
> > It just feels like you want to have a cake (non-local file i/o) and not
> > pay for it (supply dependencies).
> 
> No, he just wants a sane default implementation.  If the CUPS backend 
> isn't compiled, the print dialog still comes up, and you can at least 
> print to a file.  A dialog that presents "Operation not supported" to 
> the user is pretty poor, IMO.  As Allin suggested, it would be nice if 
> there was at least a default fallback implementation that tries the 
> BROWSER env var, and if that doesn't work, tries a list of known browser 
> binary names until one succeeds.

You only get "operation not supported" when you're trying to access a
non-local file. The default implementation handles all local files and
file types. I don't see this as not sane.

However, sure we could select a few uri types and add special case
things like looking at env vars. I wouldn't mind a patch for this, but
its hardly a major thing.