Re: 2.3 Proposed Features

[Havoc Pennington <hp redhat com>]

On Mon, Feb 03, 2003 at 01:12:15AM +0100, Christian Meyer wrote: 
> Wouldn't it be wiser to wait for gtk2.4? libegg will replace some widgets in
> gtk2.4 (what I've learned so far) which will also fix some UI issues which have
> been discussed over the last days. Don't you think it's more important to wait
> instead of shipping those issues with the next version of GNOME.
> This would be a great step to have a clean UI in GNOME2.4.
> Currently, some people are fixing bugs, like #104549. And I hope there'll
> happen more things like that.

I don't think blocking on GTK 2.4 is a good idea really. If GTK 2.4
happens to come out in time, we can include GTK 2.4 in the release,
but GTK 2.4 won't be locked down soon enough to make GNOME 2.4 depend
on it. Would send our release schedule down the tubes.

We should however have a plan for using cut-and-pasted bits of GTK,
some stuff to consider:

 - this way GNOME 2.4 can be using the new file selector UI, for
   example

 - if the cut-and-pasted bits are named in the gtk_ namespace, when 
   real GTK 2.4 comes out there will be symbol collision issues
   we need to avoid. Thus cut-and-paste bits should probably be 
   in egg_. But policy here is required.

 - we need to get these 2.4 APIs tested prior to locking them down 
   (another reason to release GTK 2.4 *after* GNOME 2.4, so we 
   are sure we have all the kinks worked out of the APIs and have the 
   UI design we want for the GTk widgets)

 - on the other hand, we're going to want the stuff landing in gtk+
   module in CVS as soon as it's relatively in shape. Which is kind of
   in conflict with having the stuff living where it's testable
   by apps that can't rely on GTK+ unstable branch.

 - perhaps instead of cut-and-paste we should install static-only
   libraries? Or even dynamic libs with -DWNCK_I_KNOW_THIS_IS_UNSTABLE
   type pedanticism.

A *possible* approach here is to kick GNOME 2.4 out as soon as we can,
say in August, which would mean we start on GNOME 2.6 in August.  If
we then plan GTK 2.4 for October, there are a couple months where
GNOME CVS HEAD could depend on GTK 2.4 and work out the final GTK
issues.

At least kind of - on the other hand, the classic release plan keeps
the main focus of development (tinderbox, release team attention) on
the stable branch for a month or two after it comes out, so GNOME 2.6
doesn't really start in earnest until October, just as GNOME 2.4
doesn't really start in earnest until March or early April.

So that would imply that getting GTK+ 2.4 APIs well-abused would mean
kicking GTK+ out to more like December. So we might want to be looking
at the libegg approach as our primary testing venue.

Havoc