After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 753232 - dconf-editor doesn't show custom default values correctly
dconf-editor doesn't show custom default values correctly
Status: RESOLVED FIXED
Product: dconf-editor
Classification: Other
Component: general
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: Arnaud B.
dconf-maint
Depends on:
Blocks:
 
 
Reported: 2015-08-04 11:24 UTC by Henri Schwarz
Modified: 2016-02-21 13:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Present default value wrt overrides. (1018 bytes, patch)
2016-02-17 01:10 UTC, Arnaud B.
none Details | Review

Description Henri Schwarz 2015-08-04 11:24:11 UTC
When setting custom default values, they are not represented correctly in dconf-editor.

See this related stackoverflow post.

http://unix.stackexchange.com/questions/220090/how-to-set-custom-default-values-for-gnome3-system-settings

The new default value is set correctly but not displayed.
Comment 1 Arnaud B. 2015-09-30 20:56:16 UTC
I think this is related to a previously reported bug[1], with a proposed patch. I’ll have a look.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=668234#c3
Comment 2 Arnaud B. 2015-10-14 01:53:02 UTC
Thanks for reporting this bug. Dconf Editor uses now in its development “master” branch GSettings to access and edit keys when possible, and that solves this problem (and it works as the patch available in the other bug). The correction will be available in the 3.20 release, in six months.
Comment 3 Mike Gorse 2016-02-16 23:49:31 UTC
I am still seeing some behavior that seems odd to me. To reproduce:

Create a gsettings override file with the following:
[org.gnome.desktop.background]
picture-uri = "file:///usr/share/wallpapers/openSUSE-default.xml"

cat <<eof >/etc/dconf/profile/user
user-db:user
system-db:uow
service-db:keyfile/user
eof

cat <<eof >/etc/dconf/db/uow.d/org_gnome_desktop
[org/gnome/desktop/background]
picture-uri='file:///usr/share/pixmaps/backgrounds/uow_photos/black_0.5/flags1_black_0.5.jpg'
picture-options='zoom'
eof

Now navigate to /org/gnome/desktop/background/picture-uri in dconf-editor

The default value listed by dconf-editor is the default specified in the
gsettings override, but this is different from the value returned by running
gsettings get org.gnome.desktop.background picture-uri

The latter takes the value from the dconf database. I suspect that this
results from using g_settings_schema_key_get_default_value. The
documentation has this:

 * Note that this is the default value according to the schema.  System
 * administrator defaults and lockdown are not visible via this API.

The patch I originally wrote, for the downstream SLED bug, used
g_settings_get_default_value instead; it is documented that it may
return a different value from g_settings_schema_key_get_default_value()
if the system administrator has provided a default value.
Comment 4 Arnaud B. 2016-02-17 01:10:15 UTC
Created attachment 321453 [details] [review]
Present default value wrt overrides.

Without real tests from my side: this patch brings the behaviour you have in mind, right? The two informations should be presented in distinct rows in fact, but I didn’t took the time for reworking that this cycle (there should be only one presented when there’s no way to know if there’s an override).
Comment 5 Mike Gorse 2016-02-17 03:59:13 UTC
(In reply to Arnaud B. from comment #4)
> Created attachment 321453 [details] [review] [review]
> Present default value wrt overrides.
> 
> Without real tests from my side: this patch brings the behaviour you have in
> mind, right? The two informations should be presented in distinct rows in
> fact, but I didn’t took the time for reworking that this cycle (there should
> be only one presented when there’s no way to know if there’s an override).

That makes sense. ANyway, I tested your patch with the case that I described, and it does what I'd expect / shows the default that gsettings thinks is the default.
Comment 6 Arnaud B. 2016-02-21 13:24:31 UTC
I pushed the patch, as I don’t see anything that could go wrong with that. The presentation of the two informations will be for next cycle, probably. Thanks for the comments and tests. =)