! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Object property reset to the default value when a binding is connected
Status:
RESOLVED: INVALID

Comments

Description Nick Schermer editbugs 2008-10-21 17:10:49 CEST
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.
Comment 1 Brian J. Tarricone (not reading bugmail) 2008-10-21 18:18:15 CEST
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?
Comment 2 Nick Schermer editbugs 2008-10-21 19:41:01 CEST
- 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.
Comment 3 Brian J. Tarricone (not reading bugmail) 2008-10-24 21:13:36 CEST
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.
Comment 4 Nick Schermer editbugs 2008-10-26 14:20:11 CET
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).
Comment 5 Brian J. Tarricone (not reading bugmail) 2008-10-29 02:56:55 CET
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?

Bug #4511

Reported by:
Nick Schermer
Reported on: 2008-10-21
Last modified on: 2015-02-16

People

Assignee:
Brian J. Tarricone (not reading bugmail)
CC List:
0 users

Version

Version:
4.5.91 (4.6beta1)

Attachments

Additional information