Re: GLib plans for the next cycle

["Brian J. Tarricone" <bjt23 cornell edu>]

Alexander Larsson wrote:
> On Mon, 2009-04-20 at 18:45 -0400, Allin Cottrell wrote:
> > On Mon, 20 Apr 2009, Alexander Larsson wrote:
> >
> > > gvfs needs a session bus, not a system bus, so you're falling back to a
> > > non-gvfs system. Thus no http support.
>>
> > OK, I suppose I can get this working on my own system, but my main
> > point is: why does GTK include a function such as gtk_show_uri
> > which depends on a big stack of unspecified stuff?  At least this
> > should be mentioned in the documentation.  As I said before, up
> > till very recently one has been able to rely on GTK functions
> > "just working" so long as the compile-time dependencies are
> > satisfied.
>
> Thats not totally true, there are optional dependencies in gtk+ before
> gvfs. Things like shared memory, cups backend, etc.
>
> But, all the gio calls *do* work even with gvfs totally absent. The only
> thing that doesn't work is things involving non-local files, and I don't
> understand how you expect that to ever work without depenencies.
>
> gtk_show_uri() for instance is an excellent function to use to launch
> the users default app to open a specific file, based on its mimetype.
>
> 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.

	-brian