GNOME Bugzilla – Bug 792990
Remove direct dconf dependency
Last modified: 2021-06-10 21:22:20 UTC
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.
FYI: Fedora 24 added --disable-migration in Oct 2015 (https://bugzilla.redhat.com/show_bug.cgi?id=1276525). Debian did the same in Mar 2017, Ubuntu auto-followed at some point.
(In reply to Egmont Koblinger from comment #0) > 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), At least that bit of code can be improved by the new (since then) g_settings_schema_list_keys(). > 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? IIRC there are 'issues' with the delayed settings, that aren't going to be fixed soon (since gsettings is unmaintained), so that's not the way to go. Bug 765965 would add API to GSettings that's basically DConfChangeset, but is stalled too :-( I guess this function could be rewritten to take a GSettings* profile as input instead of the UUID, use g_settings_schema_list_keys() to get the keys, loop over the keys doing g_settings_get_value(profile,...) + g_settings_set_value(new_profile,...). I don't really remember why I used DConfChangeset directly here; perhaps because doing it the way described above did result in excessive change notifications on the backend? But maybe that's not the case anymore? > 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. Ok.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7822.