Re: GAL vs gnome-2.0

[Havoc Pennington <hp redhat com>]

Larry Ewing <lewing ximian com> writes:
> 
> I think you completely missed the point here.  It is precisely because
> the current stable gtk+ is so poor with respect to i18n that gal has a
> huge number of gross hacks trying to address such issues.  The stable
> platform has moved so slowly that we end up falling all over ourselves
> trying to work around it.
> 

Let me be clear, I have _no_ objection to GAL. Workarounds to address
platform deficiencies are _fine_. My point has nothing to do with
whether or not GAL has gross hacks, and I'm not blaming GAL for having
them.

But, you imply that we should move GTK faster to avoid the
workarounds, and that it's too slow-moving now. Let me point out that
the slowness is not because "nothing is perfect enough," it's because
fixing the problem with something other than workarounds -
e.g. writing pango and deploying it, moving to Unicode throughout -
takes a long time. Moving quick-to-write workarounds into GTK doesn't
avoid workarounds, it just _moves_ them. ;-)

I'd agree that GTK should have released many months ago, but this
wasn't because of bouncing imperfect patches that existed... it's more
because of accepting patches, i.e. feature creep. And still, we are
punting things that people are screaming about, and people are
complaining about how hard it is to get patches in. While from my
standpoint patches are landing as fast as Owen can cursorily glance at
them, and he still has a largish backlog.

Anyhow, I'd agree more frequent releases would be good and are
possible. This is hopefully what will happen for 2.2. But I don't know
how you propose to move the core forward more quickly overall. There's
simply X amount of work to do, that takes Y time. As is well known, in
the software world it is hard to change the Y time if you have fixed
requirements for the X amount of work. Plus, I don't think anyone
wants to port to an incompatible GTK more than once every couple years
anyhow (thus binary compatibility planned for 2.2 short-term release).

So this means workarounds are good and necessary. But trying to
support them long-term just creates an enormous unwieldy incoherent
platform. A coherent complete platform _will_ _take_ _time_. It will
have to move at "GTK speed." There is no silver bullet.

Blaming GTK patch-acceptance policy is just an excuse - patches go in
to GTK every day. A number of eel features actually have gone in to
GTK 2, because people submitted them and did the work to shape them
up. Patches go in and work is done. Sadly, software doesn't get
finished overnight.

Havoc