Re: control-center 2.13.90 released

[Davyd Madeley <davyd madeley id au>]

On Tue, Jan 31, 2006 at 08:58:22AM -0500, Rodney Dawes wrote:
> On Tue, 2006-01-31 at 12:49 +0000, Calum Benson wrote:
> > On Mon, 2006-01-30 at 13:52 -0700, Elijah Newren wrote:
> > 
> > > I also feel that it looks odd and out of place (Why else would I click
> > > on a different image than to have it be my background?).  It appears
> > > this was done because the change was too slow -- at least that's the
> > > valid reason I could find at
> > > http://bugzilla.gnome.org/show_bug.cgi?id=327335.  I'm with Federico
> > > though in thinking we should make it fast instead.
> > 
> > And in the meantime, a bit of pointer feedback would probably relieve
> > any "why is nothing happening?" symptoms on the instant-apply front.
> 
> The gnome-background-properties dialog has no idea how long it will
> actually take for the settings to take effect, as it does not control
> the actual drawing on the background. The gconf calls to set the keys
> succeed and return instantly, which means that changing the pointer in
> the capplet itself, based on that information, would be totally useless.
> A timeout would still be needed, to slow the UI down.

At this stage in the game, I think we should look at doing three
things:
 (1) reverting the UI change, it is a bandaid fix to a deeper
     problem;
 (2) shipping GNOME 2.14 with gtk-engines 2.6, leaving people who
     giving us more time to optimise gtk-engines/cairo/X
 (3) attempting to profile Nautilus and find out why it is that
     little bit slower

It will be absolutely appaulling if we ship Cairo based gtk-engines
(which most people will not appreciate) while claiming that we've
sped up all these things (pango, GSlice, etc.) only to have all of
our actual window drawing shot to pieces. Once we're on 2.15, we can
start using the new gtk-engines again, hopefully with Cairo 1.2 and
start looking at what is making it slow (still).

People have suggested adding D-BUS interfaces to Nautilus to know
when the background is done being changed, but I think this is also
unrequired. We obviously have a fast code path and a slow code path,
and there has to be a logical explanation for this. If it is
unfixable, then perhaps D-BUS should be our bandaid.

--d

-- 
Davyd Madeley

http://www.davyd.id.au/
08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA