Remove direct dconf dependency
@egmontkob
Submitted by Egmont Koblinger Link to original bug (#792990)
Description
Cloning a profile only works with dconf settings backend. It should work with any backend.
It uses a weird mixture of dconf and gsettings calls, e.g. uses gsettings for getting the list of all keys (and even has a FIXME about how ugly that is, in clone_child(), and the method is deprecated by the way), and then dconf to clone them.
This makes it pretty inconvenient to fix a FIXME in the pending prefs merge change: see the comments above the two gtk_list_box_invalidate_sort() calls in bug 722114's patch v0.5. Inconvenient enough that I don't want to do this until this cleanup here is addressed :-)
I guess the main reason for using dconf directly is to batch up things in a dconf_changeset and then apply at once (atomicity is not required since the profile isn't yet added to the list; speed matters though). But I'm wondering, isn't it what g_settings_delay() / g_settings_apply() also does?
There's another place in the source where dconf is used directly, and that's the gconf migration. We could convert this to gsettings too, but IMO let's just drop this whole thing. The gconf -> gsettings switch happened in g-t 3.8, released 5 years ago in March 2013. Assuming we'll only address this bug for g-t 3.30 (Sep 2018), someone will have to jump 6 years of gnome-terminal version straight to lose their settings. I think it's time to retire it.
Version: 3.27.x