Re: GAL vs gnome-2.0

[Havoc Pennington <hp redhat com>]

Jody Goldberg <jgoldberg home com> writes:
> gal/eel in their current forms are not suitable for use as platform
> libraries.  They have been forced into existence to serve 2 needs.
> 
>     - A place to provide application utilities
>     - A staging area for new development.
> 
> The gnome platform suffers from a lack of coherent shared
> application utilities.  Things like some centralised locale
> utilities for date/value formating/parsing,  GnomeRecentlyUsed,
> plugin systems, etc.  These have been reinvented for every major
> application.  IMHO that is due to the stagnation of core. 

Hopefully I can give some productive insight here.

I'd say that gtk-devel-list has at least 10 times the technical
discussion volume of gnome-libs-devel/gnome-hackers, with tons of
bugzilla traffic and several incoming patches daily. I don't think
that's stagnation exactly. ;-)

There is a lot of activity, it's just not the activity you prioritize
as the very-technically-savvy author of a large open source
consumer/office desktop application. Fair enough, but you have to
concede that you are the 1% case - GTK's userbase is much larger than
that.

It seems like you're imagining an impossible situation, which is that
we can maintain the core sanely while also filling in all bullet
points at once. That's simply not realistic. To meet your preferred
priorities would involve deprioritizing a lot of requirements that
matter. It's not possible to do everything at once - already we punted
important core features such as multihead due to lack of
time/resources.

GTK has its requirements for a reason:

 - much less breakage between versions than libgal
 - many fewer incompatible versions
 - cross-platform
 - does not launch external processes that would interfere with 
   many uses
 - internationalization properly considered
 - language bindings properly considered
 - accessibility properly considered
 - coherency/consistency of the whole API considered (crucial for
   competition with Qt/Swing/WinForms)
 - maintainable at a high quality level with available resources
 - some chance of getting complete documentation written

People think getting patches into GTK is hard because they actually
have to finish the patch and meet all those requirements. And they
just want a quick hack that works for them.

It's fine to want a quick hack, but I think silly to be annoyed that
it doesn't go into the core as a pitfall for the 95% of developers who
don't even read any gnome.org mailing lists.

So really IMO libgal is an ideal situation; the users of libgal have
different requirements, which are sort of centered around what they
are doing and their level of GNOME involvement. So they create a lib
that meets their needs. There's no problem with that. It lets everyone
be happy. Trying to shove everything into GTK would just annoy all
classes of user.

You characterize GTK by saying "nothing is perfect enough" to go in,
but I think you only say that because you don't consider the GTK
requirements important, while other people do consider them
important. i.e. you are dismissing the GTK requirements as
hoop-jumping or a foolish pursuit of perfection. However to someone
who runs their system in Japanese the i18n requirement might be more
than that. ;-)

Because I think the GTK requirements are important, I would like to
see them propagated upward to more libraries that should be supported;
and I think we've been doing that. However I'd also like to see a
bright line between libs that try to care about these things and those
that don't.

> If we want to avoid the current problem where libgnome development
> only starts when gtk freezes, then gets cut off due to time
> constraints we need fluid libraries like gal/eel to work in.

There are fundamental problems with an overhigh library stack, for
example we can't wait for them all to stabilize in serial (and it's
infeasible to develop them all in parallel).

Also, it's by definition not conducive to a coherent platform (my
favorite examples being the current location of gnome-vfs in the
stack, and the previous location of gdk-pixbuf in the stack).

So I would agree we need "prototype" libs, and things have to trickle
down. However the trickle down has to be done by the prototype libs
being converted to production quality and the platform integration
work being done, trickle down does not mean doing a cp of
prototype-quality stuff into the production module.

> Chasing their requirements
> is admittedly difficult, but they patch a necessary hole in our
> platform.

The thing is that they _don't_ patch the hole, not for most
people. They patch the hole for people writing open source apps that
don't have to be stable or production-deployed in the near future.

That's why it's necessary to a) have things like libgal, for those
people and b) be sure we don't ruin the core for everyone else.

> These libraries are not strictly for insiders.  They are for anyone
> developing a high level application. 

They aren't. If someone was on a deadline or had specific
stability/compatibility requirements or wanted to know that things
would work properly for i18n etc., they would be crazy to use these
libs. Also, introducing lots of deprecated, broken, inconsistent,
confusing, etc. APIs into the core really hoses the more naive
developers.

You're ignoring a large target audience of a supported platform when
you say "anyone" here.

There is no free lunch. If people do the work to make things actually
meet the requirements for a core library, then the stuff can go in the
core. And we can broaden the core to include more libraries as those
libs start to meet the "perfection" requirements. Otherwise features
should go in the "incomplete hacks" libraries. And we should clearly
communicate the dividing line to people. I don't see what's wrong with
that.

Getting a complete platform is a lot of work. Putting in everything
half-finished just so we have the bullet points and screen shots does
not move us closer to being done, it just ruins our credibility with
people who care about the more difficult-to-achieve requirements.

My point in short is that while I agree with you that the platform has
holes, I really don't agree that something like gal deploys a solution
to that problem; it's just a prototype that moves us closer to
eventually deploying something when we do all of the necessary
additional work.


(I don't think we're arguing about anything substantive, the point of
this mail is just to try and talk enough to get on the same page about
this sort of thing.)

Havoc