Re: another gnome-libs .02

[Havoc Pennington <hp redhat com>]

George <jirka 5z com> writes:
> Well, one thing that should not arise however is that there be 1000's of
> small libs with one unmaintained widget in there slowing down releases
> because a couple apps depend on it.  Basically it's far easier to maintain a
> bunch of widgets/features if they are in one lib.  If some small thing
> happens that requires a small change to each widget.  The gnome-libs
> maintainer person will go through and do it to all widgets with relative
> ease.  If they are distributed over a bunch of other libs this will not get
> done, or will get done slowly and problematically.

I think you're simply wrong about this. A giant lib is "less work"
only if you don't consider that you've just forced dozens of unrelated
modules that could have been done in parallel on different schedules
to work together. Fred Brooks would have your head on a plate. ;-)

You want to avoid trying to create the Single Giant Huge System, and
create lots of little useful independent stuff.

We already have the "require a small change to each widget" case -
what do you think GTK 2 does? There are thousands of GTK apps and
hundreds of GTK widgets in numerous modules. But because those things
are separate, with their own maintainers, we can easily parallelize
the work, and it will get done quickly and painlessly. If we had all
of libnautilus-extensions, GAL, libgnomeui, GtkExtra, GtkHTML, and
whatever else in GTK+ then we wouldn't be _able_ to change anything,
because we'd be completely swamped as the sole maintainers of this
enormous load of stuff.

> >     - libraries like GAL, libnautilus-extensions, etc. which 
> >       are not really supported for general-purpose use yet, 
> >       but allow people to experiment with new widgets and share
> >       them between some set of apps
> 
> Except that these libraries are discouraged for use by apps outside a "chosen
> few".

Which is _absolutely the correct thing to do_. Let me say that again:
it is ABSOLUTELY the correct thing. If a widget is not ready, then it
should be discouraged for people that don't know what they're getting
into. If a widget isn't of general interest, then it should be in an
application-specific module. When it's finished and ready and of
general interest, then as I've said it should then and only then go
into a general-purpose lib like libgnomeui or GTK.

Let me use this example from GTK: GtkGamma, GtkCurve, and maybe
GtkInputDialog are not of general interest. So they stagnate in GTK
where we consider them bloat. If they were in a
"libgtkimageapplications" where the GIMP and other image-related apps
could use them, they would be free to develop, get featuritis of
interest to image apps, and generally be far more useful, and they
wouldn't have to be maintained by us.

The stuff in GAL is (mostly) either a hack that's getting merged later
into GTK/libgnomeui (e.g. paned and scrolled window forks), or not
finished. So Miguel says he discourages people from using it. As he
should, because it isn't something you want to use if you're looking
for a stable lib. But it's fine for the set of apps that are also
unstable and are prepared to sync their release schedule with GAL.

> 
> >     - libraries like libgtkhtml that just contain a single 
> >       large feature
>
> Works only for large features, not fairly minor widgets/features.

Thus I said "large feature" ;-)

> >     - Bonobo components/controls that are shipped as their own
> >       independent module. For example I think it would be 
> >       reasonable to do GnomeSelector as a Bonobo component.
> 
> I don't think so.  I don't see how this would help or be useful.  This would
> make it's use far harder in fact.  Some widgets I agree on this, such as
> gnome-calculator.
> 

Leaving aside the GnomeSelector example, it's useful in general
because it keeps things modular and separate and able to evolve at
their own rate in the way that makes sense for a particular set of
users, rather than forcing everything to be general-purpose and
forcing all apps to endure a bunch of not-really-general-purpose
features.

As an aside, if a Bonobo control is too heavy or too hard to use, then
that's a flaw in Bonobo we need to fix. In Delphi, and on Windows, all
widgets are their own controls. (Some happen to be bundled into one
DLL I guess, but this is not something app developers have to care
about.) From the developer perspective there are only components,
there isn't an arbitrary libraries vs. components line.

But while waiting for that to get fixed, for smaller stuff let's have
libraries with clear scope and reason for existence. If we need a
"libgnomeuiprototypes" let's have that. If we need
"libpanelandnautilus" let's have that. But each module should make
sense and have a clear maintainer and clear bounds on what goes in
there when.

What I'm very, very strongly opposed to is "as soon as we use a piece
of code in two places, put it in gnome-libs" or "5% of people could
maybe use this, put it in gnome-libs." That is death. Evil. Bad bad
bad. Stampeding herd of frothing-at-the-mouth GEGL rolling over us.

Clear bounds on the libraries. Parallelization of maintenance. Minimal
interdependencies.

Havoc