Re: [Evolution-hackers] evolution-1.4 method trace ...

[Larry Ewing <lewing ximian com>]

On Fri, 2003-06-20 at 06:09, Rodrigo Moya wrote:
> On Wed, 2003-06-18 at 17:46, Rodrigo Moya wrote:
> > On Mon, 2003-06-16 at 16:41, Larry Ewing wrote:
> > > On Sun, 2003-06-15 at 21:35, Not Zed wrote:
> > > > > speaking of what, here's a patch to PRELOAD_RECURSIVE in
> > > > > e-config-listener.
> > > > > 
> > > > > > Although maybe it's better to have a separate GConfClient per component
> > > > > > to make sure they don't react to a "value_changed" when they shouldn't.
> > > > > > 
> > > > > maybe all GConf uses should use the e-config-listener thing in e-util.
> > > > 
> > > > Ugh, i thought we'd finally got rid of all that snot :(
> > > 
> > > What does e-config-listener do that gconf doesn't anyway?  Or is still
> > > around just because it was more trouble to changed everywhere that used
> > > it?
> > > 
> > it just wraps GConf access, so it's got nothing more nothing less than
> > GConf. It was created to ease the migration from bonobo-conf to GConf.
> > 
> > But now, it could be used to share the same GConfClient between all
> > components and the shell, for instance.
> > 
> sorry, I was wrong. It offers more than GConf, since it caches the
> values, and updates them live (via GConf notifications), so when clients
> access a key via EConfigListener, if it's already in the cache, no call
> to GConf is made.
> 
> So, using EConfigListener allows us to reduce significantly the number
> of GConf calls.
> 

Doesn't gconf cache the values in the gconf client already?  I thought
that was the whole point.

--Larry