Re: GLib plans for the next cycle

[Allin Cottrell <cottrell wfu edu>]

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).

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!

Allin Cottrell