Strategies for multiple gconf notifications

I sent this to the gconf-list as well, but I’m posting it here in case someone has some generic code that I can steal, or has some better idea.

Say I have an intensive process that should be rerun in response to changes in any one of twenty GConf 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?

At the moment, I think the only solution is to 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. That would not avoid all excess notifications, but it could avoid most.

Note that you can’t just turn off notification while making the changes, because the notification happens later, after you’ve turned notification back on again. It’s asynchronous.

6 thoughts on “Strategies for multiple gconf notifications

  1. The process could just wait after receiving a change notification to see if any more come in…

  2. suggestion of whyohwhyohwhyoh in the mugshot thingy: “make your app stop listening for a while after an update”

  3. That, and the possibility of aborting early on if yet another notification goes through after the program timed out after the first notification?

    Of course, you probably shouldn’t always abort the “intensive process” if you receive new notifications lest you stop forward progress. But maybe you could do it if you have recently run the “intensive process” and if the current invocation of the “intensive process” is say less than 10% done.

  4. You could have a gconf key ‘config_freeze’, which (when 1) causes your app to ignore all config events, and when 0, causes it to re-read the whole config.

  5. mibus, a get for that key will be true as soon as you set it, which is well before the notifications actually arrive.

Comments are closed.