Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)



On Thu, 2005-06-09 at 12:10 +0100, Gustavo J. A. M. Carneiro wrote:
>   It has not been tested it was too soon to test.  Why are people so
> afraid of gtk+ 2.7 without even trying it?  It really is quite stable
> now.

I think it's because in these enlightened times, people use the GNOME
stack that comes out of jhbuild or Ubuntu Breezy. Both of these
distribution methods are semi-official; jhbuild is meant to have "The
next version of GNOME", Breezy is "The next version of Ubuntu", and
switching to 2.7 for a trial period *without* having this conversation
is ugly and liable to confuse people about what was actually decided.

>   And Cairo does help developers significantly.  Anyone doing any kind
> of drawing and printing will know what I mean.  Like, imagine how
> abiword/gnumeric/criawips would benefit from this.  Gnome Print is not
> an option for most of these programs simply because it's a "Gnome
> library" thus "not cross platform" or "needs gnome".  There's a great
> bias against gnome libraries nowadays, unfortunately...
> 
>   And even if it is slower now, it potencially may become much faster
> than current X11 drawing model, perhaps even when gtk+ 2.8 gets
> released.  Please stop gtk/cairo FUD.

Hey hey hey, let's stay calm here. GNOME necessarily works on a
short-term-benefit model; the question we need to ask is "Is going to
GTK+ 2.8 in less than 6 months *definitely* not going to have any
negative implications on that version of GNOME?" And it's a fair
question to ask, because last time we did this the answer was "Yes, it
did."

We're blatantly going to use GTK+ 2.8 by 2.14 at the latest, but GTK+
does work on a cycle with a longer feature-implementing stage, and so
necessarily a longer improvements-and-bug-fixing stage. Which is fine.
But we need to be careful about it.

No-one was implying that Cairo was a Bad Idea (tm), only whether we
could be >99% sure of it being as stable as and as fast as the current
stable GTK+ in a relatively short timescale.

-- 
Andrew




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]