GNOME Bugzilla – Bug 750257
GSettings changed signal should clearly state the order required
Last modified: 2016-07-17 03:28:28 UTC
Because of https://git.gnome.org/browse/glib/commit/gio/gsettings.c?id=8ff5668a458344da22d30491e3ce726d861b3619 It ought to be clearly documented in GSettings changed signal's documentation the order you have to do things to get the signal enabled. i.e. something like this: "NOTE: to get the changed::x signal you must first connect to the signal then read the x value from GSettings"
It already says so in the description: Signals are only guaranteed to be emitted for a given key after you have read the value of that key while a signal handler was connected for that key. https://developer.gnome.org/gio/stable/GSettings.html#GSettings.description Where would you want additional clarification?
I was thinking in the changed signal documentation itself: https://developer.gnome.org/gio/stable/GSettings.html#GSettings-changed
Created attachment 304404 [details] [review] gsettings: clarify changed signal documentation That's a good point. Thanks.
Interesting commit in comment 0 ! "It's also possible to argue that it is completely valid to have read a value and _then_ established a change signal connection under the (correct) assumption that it would not have been possible to miss a change signal by virtue of not having returned to the mainloop. Although this argument is true, this pattern is extremely non-idiomatic, and the problem is easily avoided by doing things in the usual order. " This is the first I heard of this, and I don't think the 'usual order' is connect-then-read, in fact e.g. in gnome-terminal all settings (not using g_settings_bind) are read-then-connect, under just this assumption mentioned. This pattern certainly isn't 'non-idiomatic', whatever that means in this context.
Review of attachment 304404 [details] [review]: Yeah, that looks good to me and clarifies the issue.
Attachment 304404 [details] pushed as 0e5e3d0 - gsettings: clarify changed signal documentation