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 649408 - Keys without a schema can't be deleted
Keys without a schema can't be deleted
Status: RESOLVED FIXED
Product: dconf-editor
Classification: Other
Component: general
0.7.x
Other Linux
: Normal normal
: ---
Assigned To: dconf-editor maintainer(s)
dconf-editor maintainer(s)
: 664278 768145 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-04 20:22 UTC by bugzilla-gnome
Modified: 2018-02-09 09:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description bugzilla-gnome 2011-05-04 20:22:31 UTC
There is no way to unset(remove) keys with dconf-editor. Unlike gconf xml format, dconf's file format is binary. Which means it is completely inaccessible without some form of editor.
Comment 1 Allison Karlitskaya (desrt) 2011-05-08 16:15:11 UTC
The editor has a button to reset to the default value.  At this point the key has been removed from the database.

Most of the keys shown in the editor are from the schema.  Those are not meant to be modified by users -- to get rid of them you essentially have to remove the package associated with them.
Comment 2 bugzilla-gnome 2011-05-10 18:13:32 UTC
There are many entries that are optional, like launcher icons. In org.gnome.gnome-panel.layout.objects I have one object-{number} per launcher icon. In addition I have clock, menu-bar, notification-area, user-menu, window-list, and workspace-switcher. If I want to get rid of a launcher, how am I suppose to get rid of object-{number}? I might also want to get rid of say workspace-switcher.

I understand it is schema based, but schema based is really the wrong model. It also really isn't being used in that way.
Comment 3 Robert Ancell 2011-05-12 08:17:50 UTC
I think the bug here is keys without a schema can't be deleted, is that correct?
Comment 4 Miguel Aguilar 2011-07-14 13:46:50 UTC
Yes, that is. When you delete a package, the keys still appear with a message "No schema". Would be interesting to delete these keys.
Comment 5 Ildar 2012-10-15 06:00:59 UTC
One should change the Summary to "keys without a schema can't be deleted"
Comment 6 Geert Janssens 2013-02-27 16:19:53 UTC
Ildar: done. I would expect you could have done it yourself though or were you unsure about your choice of title ?
Comment 7 Ildar 2013-02-28 11:05:36 UTC
Geert: it's not hard to do that. But I'm a kind of "shy" making big changes to bugs I didn't report.
Comment 8 Geert Janssens 2013-02-28 12:33:45 UTC
Ildar: that's fair. From you comment I thought you were a bug triager. Those people are used to improve on bugs that are not theirs. I just changed it because I saw no one dispute your suggestion (though I'm not a bug triager myself, at least not for the dconf project).

Enough meta conversation. Hopefully someone will fix this missing functionality.
Comment 9 André Klapper 2015-02-22 12:23:05 UTC
[moving dconf>editor tickets to dconf-editor product. See bug 744791]
Comment 10 Arnaud B. 2015-09-21 15:55:16 UTC
*** Bug 664278 has been marked as a duplicate of this bug. ***
Comment 11 Arnaud B. 2016-06-28 19:31:55 UTC
*** Bug 768145 has been marked as a duplicate of this bug. ***
Comment 12 Arnaud B. 2016-08-01 10:36:47 UTC
Removing keys entries that do not have a schema will be doable in the 3.22 version of dconf-editor (or whatever its name is at the release), that will be available in september.

For now, there’s no “list of apparent orphans” (see dublicate bug 664278), but it probably will come in another release (I want to exclude keys that are known to have a relocatable schema).
Comment 13 Ildar 2018-02-09 06:47:34 UTC
I confirm it works. Time to close?
Comment 14 Arnaud B. 2018-02-09 09:22:15 UTC
There’s no “big button to clean dconf database” for now, as notably suggested in duplicate bug 664278. But that’s more or less doable now (after the to-be-released 3.28), as we can finally map relocatable schemas to the wanted path(s). That “just” needs design… I opened bug 793326 to discuss about it, so closing here.