Migrate from GConf to GSettings
Port all packages on the desktop spin from GConf to GSettings
- Name: Desktop SIG
- Email: firstname.lastname@example.org
- Targeted release: Fedora 17
- Last updated: 2012-08-23
- Percentage of completion: 90%
Most GNOME 3 modules are already ported to GSettings, but GConf is still getting pulled in.
The gnome-shell/mutter/metacity port has been merged upstream. The control-center/gnome-settings-daemon port too. The evolution/evolution-data-server port has been merged upstream too. The remaining GNOME modules mainly block on list functionality being added to GSettings: gnome-terminal, libgnome-media-profiles, aisleriot.
For details status, see https://live.gnome.org/GnomeGoals/GSettingsMigration
The GSettings class provides a convenient API for storing and retrieving application settings, similar to GConf.
dconf is a low-level configuration system. Its main purpose is to provide a backend to GSettings on platforms that don't already have configuration storage systems. dconf is the GSettings backend on Linux.
Benefit to Fedora
Configuring desktop applications and settings will be simpler, because there is only one place where the settings get store instead of two. We get to drop a number of deprecated modules (such as ORBit) which were getting pulled into the desktop spin via the GConf dependency.
We have to provide patches for all packages on the desktop spin that still depend on GConf. These patches should go upstream. See http://live.gnome.org/GnomeGoals/GSettingsMigration for upstream tracking of affected modules.
The full list on the F16alpha live cd:
How To Test
- . Install the desktop spin
- . Verify that GConf is not in the package list.
Mostly unchanged. One area where benefits might be visible is when using multiple parallel logins with a shared NFS home directory. This should work better in a dconf-only desktop.
If we don't succeed, GConf will continue to get pulled into the desktop spin by dependencies. Packages can be ported from GConf to GSettings one-by-one, though. There is no need to revert successfully ported packages.