I want my GConf notifications
While hacking a little bit with GConf I found what IMHO is an undesirable behaviour of GConf. I think most of developers will agree because you don’t want your application to run in a different way than the one you expected when you designed it. And this happens in the following situation:
I set up a GConfClient to listen to changes in keys under a specific directory. I wrote also a handler for this GConf notifications hoping that I’ll get every change in those keys (the API doc literally says “Any changes to keys below this directory will cause the “value_changed” signal to be emitted”). So I relied in this GConf notification handler some important code of my application. But, while executing the application I realized that I was not getting some notifications even tough I was completely sure that I was setting a new value in the GConf key. So, I had to take a deeper look…
I verified that the GConf server was issuing a notification for every change I made, so the problem should be in the client. Looking at the GConfClient code I found the following in the notify_from_server_callback function:
changed = gconf_client_cache (client, FALSE, entry, TRUE); if (!changed) return; /* don't do the notify */ gconf_client_queue_notify (client, entry->key);
What? This means that I won’t get notifications if the key is already updated in the client cache? What’s the reason for such a behaviour? I don’t think this is what a developer expects, specially for a system that uses idles for notifications (you could never be sure when you’ll get it), because it could cause things like the one that was happening to me:
- As a response to a user action I was setting a new value to a GConf key
- Before the GConfServer notified the GConfClient, there was some other code that was trying to get the new value of the same key
- GConf cached the new value in the client while doing the get operation
- The GConfClient received the GConfServer notification, but was not issuing a notification because the value was already updated
- I was scratching my head trying to figure out what the hell was happening …
So, IMHO there are two possibilities
- Always notify
- Write in bold 46-point sized font that sometimes you could not get notifications because of that
Anyway, it’s always good to look into the guts of the software you use.










Im guessing gconf does that to avoid endless loops in bad programs.
That is, your widget is set to the value from the notification, everytime your widget “changes” value it tells gconf to modify the related key. Et voila, you have an endless loop.
September 27th, 2007 at 10:31 am
Well, that’s not a reason for me, because you can end up with an infinite loop with a lot of things, like emitting a signal in a handler for that signal. The API can not fix programming errors and the situation you’re describing is a programming error.
September 27th, 2007 at 10:46 am
I think the ideal would be to avoid duplicate notifies but not suppress a notify if the item is only cached due to a get. There’s no reason you would ever need a duplicate notify, but caching due to a get is surprising and wrong.
September 27th, 2007 at 2:42 pm
I said that wrong - caching due to a get is good, suppressing notify due to a get is bad.
September 27th, 2007 at 2:43 pm
I agree with you Havoc, that’s why I posted about it, makes completely no sense for me.
September 27th, 2007 at 3:55 pm
I’ve written code using GConf before, and you’re right: sadly, the documentation isn’t entirely complete or accurate, to say the least.
I took a different approach: instead of reading the GConf source code, I just tried things, and recorded what it did. Eventually I get everything to work fine.
It would be nice if somebody went through the GConf source code and made sure all the docs were accurate and unambiguous.
September 28th, 2007 at 5:01 pm
Ken indeed, I am updating a bug about this issue to the GNOME bugzilla soon
September 28th, 2007 at 5:36 pm