Re: Strategies for multiple gconf notifications

[Havoc Pennington <hp redhat com>]

Hi,

Simon Holm Th�en wrote:
> tor, 10 05 2007 kl. 12:41 +0200, skrev Murray Cumming:
> > If I have an intensive process that should be rerun in response to any
> > one of twenty configuration keys, how might I prevent my application
> > from re-running that process 20 times instead of just once, when
> > changing all the keys at one time.
> >
> > I guess I could just append each notification key to a GList, and use a
> > g_timeout handler to notify my application about batches of changes, if
> > anything changed, at regular intervals.
> >
> > Or is there some existing API or known strategy to deal with this
> > situation?
> I believe GConfChangeSet[1] is what you're looking for.
>
> [1] http://developer.gnome.org/doc/API/2.0/gconf/gconf-gconf-changeset.html

The ChangeSet API is a placebo - it would in theory allow solving this 
problem, but the problem was never in fact solved.

A simple solution, if redoing gconf, would be to have a "pending 
notifications count" included in each notification indicating the number 
of remaining notifications from the same change set.

For now though a timeout or idle is about the only answer. Or an 
out-of-band notification like a dbus signal.

Havoc