On Fri, 2003-06-20 at 18:59, Larry Ewing wrote: > 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. > oh, does it? if so, then yes, we could just remove EConfigListener.
cheers _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
