Re: GNOME 2.0 Platform Alpha Deadline - Sep 26, 2001

Bill Gribble <grib linuxdevel com> writes: 
> I guess I'm not being very clear, sorry. Here's a listing of the
> packages in Debian that depend on libgal being installed.  As far as I
> can tell, it's a good fraction of the major GNOME applications.

Well, we just can't realistically add a GPL
mostly-destined-to-be-deprecated kitchen-sink library to the supported
platform. If people made the mistake of using it, then I am unhappy
about that, but there isn't much we can do about it now. Maybe we can
learn from the experience. But there isn't any way GNOME can support
this IMO. We should be removing libs not adding them anyhow.

I would recommend that people port to supported APIs instead. Most of
the "essential" GAL features are making it into the supported libs
with GNOME 2, the things that haven't made it are pretty trivial items
and can be cut-and-pasted. For example the Unicode stuff is in GLib 2,
and most uses of ETable can switch to TreeView since we will even have
editable cells now. The combo box can be cut-and-pasted and an
equivalent will be in GTK 2.2.
> I don't know how many of these use libgal directly.  gnucash certainly
> doesn't, but we rely on gtkhtml, so we must link against libgal.

We can presumably port gtkhtml away from gal in 2.0, I would assume
it's just using the unicode stuff or something.

>  It's just not clear to me that that's the case, and if it's
> not, it seems silly to claim that libgal isn't part of the core of
> GNOME, because every major GNOME application I can think of save
> Nautilus links against it, and it links against libgnome. 

Note that the GNOME release doesn't include any major applications,
it's just the core desktop and the libs we support.

If a "consortium" of major app authors would like to support GAL (and
they seem to do this de facto right now anyway), then they should feel
free to do so, but I don't think we can have a big hunk of GPL cruft
in the GNOME platform. 

To put this in perspective, if an ISV asks Red Hat what to use, we
would not even support gnome-libs, let alone libgal.

I do sympathize with the point, but the whole point of GAL has always
been that it has non-strict maintenance, lots of stuff gets dumped in,
it can be GPL, it can change interfaces often, etc. - this is so the
big office-type apps can move forward quickly and not wait on the

So putting it in the platform really sort of defeats the purpose, right?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]