Re: Strategies for multiple gconf notifications


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

I believe GConfChangeSet[1] is what you're looking for.


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.


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