Re: Don't bloat Gnome-libs, bloat Gtk+/Glib

[Havoc Pennington <hp redhat com>]

Hi,

Sigh. Can we PLEASE stop posting mail that amounts to "I have
technical disagreements with project XYZ. Therefore I will flame the
developers of XYZ."

Just post the fricking technical disagreements, preferably on the
devel list for XYZ. This passive-aggressive bullshit is not going to
get us anywhere.

Michael Meeks <michael ximian com> writes:
> 
>         While I agree with much of the propsal, and particularly the
> splitting of the libraries I must say I'm mildly amused that members of
> the Gtk+ team have the gall to lecture Gnome people on modularity
> [1]

Well first you need to get rid of that assumption - remember that I
wrote a good bit of stuff in gnome-libs, GConf, etc. and I hope
qualify as a "Gnome person." So this is bogus to say "GTK team
vs. GNOME people," as I've been a GNOME person longer than you have
I'm pretty sure. GNOME is certainly my motive for hacking GTK+.  Owen
and Tim have also done a good bit of GNOME hacking. So your us
vs. them intro is alarming nonsense. I've been most vocally critical
of bits of gnome-libs that I wrote _myself_.

Anyhow, I'm glad you agree with the proposal.

> instead of having a sensible system abstraction in glib,
> 'we' are pushing more and more clutter into it. eg. the new, meaner
> cleaner glib has:
> 
> Sensible:
>         * sized types: guint16 etc.
>         * generic warning/error code
>         * helpful assertion macros
>         * a niceish IO abstraction
>         * thread abstraction
>         ...
> Incredible [4]:
>         * Lots of C helpers, GList, etc.
>         * A cut down XML parser
>         * A simple lexical scanner
>         * A simple C type system
>         ...

GLib's defined goal is to be a C utility library, not to be a
portability abstraction. Therefore it includes C utilities.  Only a
small part of GLib is a portability abstraction, and it's been that
way since GLib 1.0. Some of the utilities are not really of general
interest and probably shouldn't have gone in, but people make
mistakes. GLib maintainers reject far more features than they accept,
I assure you of that.

>         And so, it becomes progressively more impossible to try and get
> people to cooperate using glib becuase it has lots of crud that people
> don't want to link to - so instead every user of GNOME and Mozilla pays
> aper function penalty.

If there's demand for separating the "portability abstraction" part
from the "utility features" part we can certainly consider that. It's
already done for some cases, e.g. gobject and gmodule.  This simply
hasn't been requested or considered. i.e. it's never been brought up
or occurred to me. Though it's fairly late in the game to do this for
GTK 2.

>         So yes, keeping the code in small modules is good, but please
> don't eternaly keep moving code into Gtk+/glib. I in no way look forward
> to the day when ORBit,bonobo,evolution,mozilla,postgress etc. have been
> 'folded' into glib/Gtk+.

I think the point you're missing is that we do have clear guidelines
for what should and should not go in, and a clear intended functional
scope for the various G* libraries. They just apparently do not agree
with yours, or you aren't familiar with them.

> [1] - increasingly it seems that the Gtk+ team want to build everything
> from GNOME into Gtk+ where it suits them to have it. Understandable in
> many ways, and often resulting in greater code quality due to the mess
> that exists in gnome-libs [3]

We want to meet the GTK+ functional goals. If that includes
functionality that overlaps with gnome-libs, then OK. But we do not
have some kind of conspiracy to absorb all stuff, just an intent to
maintain GTK+ as a general-purpose and complete GUI toolkit that
stacks up nicely against Swing, Qt, and .NET WinForms.

Our trend over time is increased modularity and separation of
functionally distinct components; GTK+ started out as one package, and
GLib was separated so people could use it in non-GUI apps. Pango and
the accessibility framework lib will be separate packages in 2.0.
Also, we're using the generic pkg-config mechanism. So there are 5
packages now, vs. 1 originally.

Could this go further? Yes, eventually it could, and when there's a
clear functional divide (normally indicated by two different userbases
or sets of application needs), further modularization would be a good
thing. If you have specific proposals I'm totally open to them.
Suggest using bugzilla.gnome.org, product GLib, Pango, or GTK+.

Flames about hypocrisy don't interest me one bit; I freely admit that
I change my mind on a regular basis, and have changed it substantially
on quite a few issues regarding the GNOME platform over the last
month, 3 months, 6 months, year, etc. What I'm interested in is our
current best ideas for the best course of action.

The purpose of discussion and argument is not to be "right," the
purpose is to reach a good conclusion based on everyone's best
ideas. I think flames like this keep people from posting their current
best ideas. Don't you agree? Well, probably not. But you should!

Havoc

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers