Created attachment 1913 Save non default property when connecting a binding. When you have an object where property value != default property value, xfconf resets the value. Same problem is that xfconf should save this 'not default' value, because it's probably changed by the user.
I'm not sure I understand, and your patch doesn't seem to do what I think it should based on your bug report. Can you explain in more detail?
- Assume you have a GObject with an int property called "foo". Default value is 1. - Add a binding to xfconf property /foo. Everything works fine, since the value of the property is still 1. Then xfconf-query the value to 2, object property is updated to 2. Still fine. - Now the code unbinds the binding and creates a new binding to xfconf property /bar, which is a property that does not exist. - Now things go wrong, the value of the object property is still 2, but xfconf resets it to the default value, 1, even tho the property /bar is not set in xfconf. So technically, xfconf should either do nothing (leave the value to 2 and wait until the property is notified and then save it) or store the property when connecting the binding if the value is not the default value.
Ok, in that case it should do nothing. When you bind to an xfconf property that doesn't exist, the gobject property shouldn't get touched. I thought that was already the case, tho; xfconf_g_binding_init() only runs the channel prop changed handler on init if xfconf_channel_get_property() returns TRUE.
Yes, and xfconf_channel_get_property() returns false, so that is not the problem. The problem is that property-changed is emitted (i have no idea why...) with a G_VALUE_TYPE() == G_TYPE_NONE, which resets the gobject property to it's default value (for the xfconf_channel_property_reset behaviour).
Er, are you sure about that? Xfconf can never return a property of type G_TYPE_NONE, since that will fail to marshal through dbus-glib. XfconfChannel will convert a dbus PropertyRemoved signal into an unset GValue (G_TYPE_INVALID), though. At any rate, I really don't see how that can ever happen. If the property isn't set in xfconf, there's no way the client can get PropertyChanged or PropertyRemoved unless there's a weird bug in the daemon. Got a test program for this?