Re: [Nautilus-list] Re: Nautilus background patch

Richard Hestilow <hestilow ximian com> writes: 
> -- I am not sure the correct way to avoid gconf notifications. I am
> fairly certain that bg_preferences_save will only generate one
> notification, as that code uses a changeset.

Heh. ;-) ChangeSet is not really atomic, just an API that could
theoretically be made atomic. So you get a notify for each key, though
"did not really change" notifies are filtered out on the client side.

Even if that were not true, however, it's suboptimal to save settings
that were not modified, since it's better to leave the default
"falling through" in that case, IMO.

> However, I am also fairly certain that you can't just ignore the
> notification by some evil "gboolean we_set_this", as that creates
> nasty race conditions. Havoc, what do you think?

I don't have the big picture here, so I'm not sure what you're asking.

In general the way to avoid notification mess:

 - only change what the user really modified
 - ignore notifications when the new value is either the same as 
   your current value, or some kind of invalid crackrock value
 - at all costs avoid setting values in response to notifications,
   even if you are setting a different key than the one you 
   were notified about.
 - keep your model code and your view code _strictly_ separated


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