Re: GLib plans for the next cycle

[David Zeuthen <david fubar dk>]

On Sun, 2009-04-19 at 20:05 -0400, Allin Cottrell wrote:
> On Sun, 19 Apr 2009, Havoc Pennington wrote:
> 
> > On Sun, Apr 19, 2009 at 9:54 AM, Tim-Philipp Müller <t i m zen co uk> wrote:
> > > You tell people not to worry. But many people clearly do seem to worry.
> >
> > Well, why don't these many people post a rational response to my
> > points? I have not seen a rebuttal to
> > http://mail.gnome.org/archives/gtk-devel-list/2009-April/msg00008.html
> >
> > If it's a legitimate concern then someone specific will turn up
> > and make a rational argument that's responsive to the points I
> > made.
> 
> Havoc may well be right with regard to libdbus, but IMO the burden
> of proof rests the other way; that is, if code that is not under
> *GPL is to be made part of glib, the onus is on those who would
> make the addition to show without a particle of doubt that the
> license is not an issue (i.e., "afaict" is not good enough).

I think it is sufficient to observe that there already is an
overwhelming amount of GPLv2+ and LGPLv2+ software already linking to
libdbus-1 (including things like GVfs) and already shipped by major
stakeholders...

> On a matter that may or may not be related, I'm concerned about
> possible "over-extension" of GTK/glib.  I've recently been trying
> to purge my GTK app of "deprecated" stuff, and I tried replacing
> gnome_url_show() with gtk_show_uri().  No go; on invoking
> gtk_show_uri() I get "operation not supported".  After some
> googling, it appears that one must have gvfs installed.  OK, I
> download, build and install gvfs.  But it doesn't help.  Gvfs as
> built on my system (without configure or compilation errors)
> apparently can't handle URIs; I suppose this facility must depend
> on yet further third-party libraries.  Avahi?  It's all
> undocumented, so I'm only guessing.
> 
> This sort of thing is new, and IMO thoroughly obnoxious: up till
> now, one could depend on GTK functions working provided one had
> successfully installed the known stack of dependencies, which were
> checked at compile time for GTK and friends.  Now we have GTK
> functions that may or may not work depending on unspecified
> dependencies.  Way NOT to go!

This is _supposed_ to work, there's already an unpleasant amount of work
in GIO to ensure that things work when things like GVfs (which requires
a modern flavor of Linux or UNIX) is not available.

Now, GIO may not work as well as when GVfs installed (e.g. automounting
storage devices won't work unless the OS actively assists with playing
games like modifying /etc/fstab) but basics like launching a program for
URIs _should_ work - e.g. http, mailto, file:///path/to/some.jpg file or
other well-known URIs schemes.

I could be wrong, but just briefly looking at the code it looks like
there is no default implementation of GDesktopAppInfoLookup in GIO,
there's only one in GVfs  (that looks up stuff in GConf under
in /desktop/gnome/url-handlers/<scheme>) so it's no surprise things
don't work if GVfs is not installed.

I think it would be reasonable if GIO at least handled file:// and maybe
also http:// and mailto:// (the former by using the MIME, the latter two
by include a search path of well-known applications like epiphany
firefox, evolution and thunderbird) and also the URI schemes used to
launch Yelp.

You should probably file a bug about this.

     David