another gnome-libs .02

[Havoc Pennington <hp redhat com>]

Hi,

Thoughts on gnome-libs.

Historical problems with gnome-libs:

 - changes have gone in haphazardly with little real review; basically 
   any feature gets accepted, backward compat gets broken in random 
   ways with no fixed policy, etc.

 - "productization" work hasn't happened - documentation, fixing
   annoying little glitches that are boring to fix, final 10% of 
   work on features doesn't get done.

 - it therefore contains a lot of stuff that should be deprecated

These problems still seem to exist in gnome-libs HEAD, traceable to
the Labs doing a bunch of half-finished mess in there a year ago. 
Some examples: gnome-recently-used isn't finished, the textfu/help
thing isn't finished, the stock system is both deprecated and 
incompatibly changed (never a good idea), blah blah.

I think we can trace this to some causes:
 
 - gnome-libs has no functional definition. There is no "this is the
   purpose of gnome-libs" statement, certainly not one that's used
   in evaluating features. So you can't say whether a feature should 
   be in there or not.

 - maintainership is too distributed; there are various people hacking 
   on it a bit in their spare time, no one really focusing on it full
   time. Miguel in principle can say yes/no on a given feature, but 
   in practice all features seem to go in, regardless of how finished
   they are or whether they make sense.

 - people feel that gnome-libs is the only place to put a piece of
   code they want to share among GNOME apps. We don't have anywhere 
   to put code that's not really ready for prime time, but we want to 
   share between panel and control center or something.

I propose the following solutions.

 - we have clear ways to share code and add to the devel platform 
   outside of gnome-libs itself. Some examples:
    - 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
    - libraries like libgtkhtml that just contain a single 
      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.

 - we modularize. explode gnome-libs into separate tarballs: zvt,
   libart, libgnome, libgnomeui, bonobo, bonobo-conf, bonobo-ui.
   To maintain convenience and platform integrity we can have the 
   libgnome/libgnomeui packages install pkg-config files that bring 
   in all the other libs, since libgnomeui will depend on all the 
   other libs. Each module should have a clear functional definition 
   and a clear, bounded scope.

 - each of these packages will have a specific maintainer appropriate 
   to that package and can be released independently. This gives 
   clear responsibility. 

 - we narrow the scope of libgnome and libgnomeui a good bit. I
   propose the scope "code that is GNOME desktop environment
   specific." That is, these are the libraries where you would put
   a feature that's really tied to the desktop environment user 
   interface. gnome-recently-used is a good example; gnome_config and 
   desktop entry stuff are a good examples. GnomeCanvas, GnomeDock,
   while they should remain in the lib for historical reasons, are 
   not something we should accept in the future. [1]

In general, we want gnome-libs to be a relatively stable, productized,
finished library. But we don't want to stop innovation or reduce code
sharing when it makes sense. So we need to have ways to share code
other than using gnome-libs.

gnome-libs used to be one big package for convenience reasons; I think
with pkg-config and Bonobo this is much less of a factor. IMO we
really need a clear functional scope for each module, clear
maintainers for each module, and modules that are small enough and
logically coherent enough that one maintainer can do a good job.

Before we discuss specific gnome-libs features for 2.0, I think it
makes a lot of sense to agree on this kind of thing. At the very
least, agree on the functional scope of gnome-libs.

Also, before we discuss what to deprecate in gnome-libs, we should
take steps to reduce the amount of deprecation that has to be done in
the future. For example, I feel fairly confident that much of what we
deprecated in GTK 2 (GtkCList, GtkText) would _never_ have made it in
to GTK with the processes and guidelines we currently have in
place. So we can deprecate that stuff and feel like we won't have to
be so deprecation-happy in the future. So I think that's an important
goal.

As a final thought, I'd point out that for GTK 1.2 and gnome-libs 1.0
we had a lot of "emergencies." For example, GtkCList sucks, but it was
way better than GtkList, and GTK would be almost an unusable toolkit
without it. So even though it's really broken, including it was maybe
the right thing to do. We could say that about a lot of libgnomeui
features we don't like anymore also.

I don't think we have many of these emergencies anymore. I came up
with a good metaphor in a mail to Maciej; once you've plugged holes in
the dam, you want to take your time and assemble the tools and
materials to repair the hole, you don't want to keep yanking out the
plug and putting in a different one. So it wouldn't make any sense to
say "CList sucks" but put in another half-ass list widget. We have the
plug already; so we could afford to spend time and effort developing a
really nice list/tree widget.

With the emergencies past, I think the general strategy should be to
leave the "plug" features backward compatible, don't cause a lot of
churn and instability there, and slowly replace plugs with really
quality implementations.

Also, for any emergencies that arise, I think we should consider a
more "experimental" library such as GAL or nautilus-extensions, or
simply a standalone Bonobo component or package, instead of putting
the plug in gnome-libs. This is especially true for features that
aren't useful in more than a few percent of third party apps.

So - I wonder how long this thread will end up being? ;-) 

Havoc

[1] When GTK is frozen and starts bouncing features, people put them
in libgnomeui even if they make sense for GTK. I think this results in
a real lack of integration and other usability problems. For example,
GtkCList can't contain a GdkPixbuf, or themes can't change the stock
icons, or whatever. This is about to happen again; GTK is freezing;
the reason GTK is freezing is to have a stable platform for finishing
GNOME 2; we should very much avoid dumping the list of punted GTK 2
features into libgnomeui. As noted in this mail:
  http://mail.gnome.org/archives/gtk-devel-list/2001-February/msg00205.html
a GTK 2.2 would be a reasonable alternative to that.





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