Re: another gnome-libs .02

[George <jirka 5z com>]

On Fri, Feb 16, 2001 at 01:27:09PM -0500, Havoc Pennington wrote:
>  - "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.

This was my focus on gnome-libs HEAD when I was working on it and I hope it
shows.  Some of these did require API changes however.

> 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.

Actually you've mentioned the 3 things that have had the above problem.  And
the 3 things that we will have to decide on which way to go.  g-r-u is
something which would be good in g-l because given experience with
gnome-history, it has a long period before it gets used.  Because first it
needs to be in the lib, then all programs will start to use it, and only some
time after then it becomes useful.  So if we want to have recently used
documents to be useful (which we wanted even before 1.0), it is critical that
this is done.  Textfu I have no clue about.  Actually all the help stuff
needs to be either finished or dumped.

>  - 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.

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 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

Except that these libraries are discouraged for use by apps outside a "chosen
few".

>     - libraries like libgtkhtml that just contain a single 
>       large feature

Works only for large features, not fairly minor widgets/features.

>     - 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.

George

-- 
George <jirka 5z com>
   A clever man commits no minor blunders.
                       -- Goethe

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