Re: another gnome-libs .02

[Havoc Pennington <hp redhat com>]

Hi,

Agree with most of your mail, a couple things - 

George <jirka 5z com> writes: 
> > 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.
> 
> Of course this is bad.  Though the 5% figure could be useful.  I mean there
> will always be such widgets.  If this is a major component that takes up
> 20megs of source then no it shouldn't be in gnome-libs.  If this is a 300
> line widget which has a sane interface and is actually useful to those 5%, I
> think it makes sense to have it there.  5% is a lot of developers.  Again I
> think this should be left more up to the task of "are there enough people
> willing to do maintanance on this", rather then arbitrairly deciding things
> are not utterly neccessary and we should drop them.

I don't think that's right, because "are there enough people" can only
be answered in the short term. The nature of free software is that
people disappear, get new jobs where they don't have time, rearrange
their priorities, or whatever. So you have to be prepared to do
maintenance yourself.

The problem with this "small widgets used by 5%" thing, besides the
fact that 300 such widgets add up to a lot of code, is that the
widgets don't even thrive in gnome-libs. Again, the example of
GtkGamma, GtkCurve, GtkInputDialog, GtkRuler in GTK; if they were in a
special library for image apps, they could get all kinds of snazzy
featuritis that those apps would enjoy, and wouldn't have to remain
small because we are basically unhappy about their existence over in
GTK-land.

> > Clear bounds on the libraries. Parallelization of maintenance. Minimal
> > interdependencies.
> 
> We only have so many people to do maintainance.  By splitting up
> libraries we do not gain more people.  Again, I'm not for putting
> everything into one big lib, I'm for not splitting this up too much.
> And I'm for having some focus on making widgets usable.

We do gain more people by splitting it up. Everyone likes to have
their own project. ;-) In fact all evidence is against what you're
saying; AFAICT no one much wants to work on gnome-libs or GTK. There
are active maintainers for tons of external widgets and libs
(GtkExtra, GAL, GtkHTML, GtkExText, etc.), and almost no one working
on the core libs.

I view the fundamental problem as "standalone components aren't as
easy to use as they are in Delphi," though I don't know how soon we
can solve that so I'm not presenting it as a GNOME 2 solution, I do
think that should be the long term solution.

Anyhow, no I don't think it's feasible to split it up too much; you
can't have a 300-line widget in a single library. But at some point
you just have to punt and say "oh well, that code can't be shared, the
cost in maintenance and modularity loss is too high." Another cost of
putting too much in a lib is that you make the lib intimidating and
hard to use. As Maciej says, just the size increase of GTK 2 makes it
scarier (though we don't yet even consider approaching Swing here...) 

So the rules we use for GTK, FWIW:

 - if the feature is useful and fundamentally Too Hard to implement
   outside the library, you at least consider hooks in the library, even
   if the feature will be little-used.

 - otherwise, the feature has to be of general interest. Where
   "general" means any kind of app is _likely_ to use it. If the
   feature is domain-specific (image apps) it should be in a
   domain-specific library. If it's maybe general-purpose but most 
   apps aren't going to use it in practice, then no.

 - just convenience or utility stuff is added with a lot of caution
   and an eye to genuine utility; a judgment call, but one indicator
   of genuine utility is that a concept is removed from the set of
   concepts the developer has to understand to complete a task.
   e.g. if you can call gtk_widget_create_pango_layout() that removes
   the concept of PangoContext. The problem with convenience/utility
   stuff is its unbounded nature; GTK 2 has 2000 entry points, if we
   took all the convenience/utility API patches we get it would be
   4000.

> Dropping widgets from gnome-libs means just about death for widgets in fact.
> Unless the widget gets put into another library.  Right now we don't have any
> other mainstream production libraries for utility widgets.  I'd be happy to
> start one if there is consensus on that this should be done and it can take
> over some libgnomeui widgets off "lesser" importance.

If you start another library it should have a clear functional scope,
such as "image app widgets" or something. I don't think "collection of
code you might be interested in" works for a library. It leads to a
crappy library that makes no sense. People are reluctant to use it
just because they can't figure out what the heck it _is_.

"Collection of code you might be interested in" is an appropriate
definition for a code repository such as CPAN. So again, the solution
to allowing that scope for something is a working component/module
system that people are willing to use in place of libraries. So you
can reasonably expect to download a single component from something
like CPAN.

I really think we have to have that by GNOME 3, if you aren't willing
to use Bonobo now then we have got to fix it. (btw it would be good to
outline the reasons you aren't willing to use Bonobo, this is an
important thing to fix.) So I think we should count on having the
component system, and not cause ourselves a lot of library bloat in
the meantime.

Clear functional scope for libgnomeui. Please please please...

Havoc