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 620121 - Migrate from GConf to GSettings
Migrate from GConf to GSettings
Status: RESOLVED FIXED
Product: eog
Classification: Core
Component: general
git master
Other All
: Normal enhancement
: GNOME3.0
Assigned To: Felix Riemann
EOG Maintainers
Depends on:
Blocks: 622558
 
 
Reported: 2010-05-30 20:58 UTC by Felix Riemann
Modified: 2010-11-20 13:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Felix Riemann 2010-05-30 20:58:09 UTC
The current development schedule (http://live.gnome.org/TwoPointThirtyone)
wants us to stop using GConf (at least directly) and to use GSettings instead.

Also, there's a GnomeGoal: http://live.gnome.org/GnomeGoals/GSettingsMigration

So, let's open this bug to track this more visibly.
Comment 1 Felix Riemann 2010-05-30 21:04:08 UTC
Assigning to me as I already started working on this over the weekend.

This migration won't be complete until other parts of the desktop are migrated, as we make use of the desktop-wide lockdown keys as well as the key for the desktop background. These keys' schemas are delivered by libgnome currently.
Comment 2 Felix Riemann 2010-06-06 14:58:12 UTC
Most parts of eog are now converted. The only parts missing concern the schemas we use from other packages and likely one or two plugins from eog-plugins (haven't checked yet). The converted stuff is in master already.
Comment 3 Felix Riemann 2010-06-06 14:59:49 UTC
Oh yeah, we still use the gconf backend and the old gconf key names.
When the day comes to drop gconf we'll need to fix the key names to match the new GSettings naming conventions (and maybe port the old settings).
Comment 4 Allison Karlitskaya (desrt) 2010-07-14 21:41:00 UTC
hi Felix

I took a peek at the GSettings migration work.  Looks pretty good.  Just a couple of comments:


  1) There is very little reason to use setenv() to manually pick the backend.  
     Please avoid doing this (so that people using dconf can use eog with it).

  2) You mentioned 'old gconf key names' but I see no examples of key names that
     do not satisfy the GSettings naming requirements.  Was this fixed already?

     The one thing I notice is that you have some paths containing '_'.  This is
     not wrong, but strange, since your keys all use '-' now.

  3) The 'transparency' key in your schema could take advantage of the enums 
     support in GSettings.

Thanks for the porting effort :)
Comment 5 Felix Riemann 2010-07-18 16:04:07 UTC
(In reply to comment #4)
> I took a peek at the GSettings migration work.  Looks pretty good.  Just a
> couple of comments:
> 
> 
>   1) There is very little reason to use setenv() to manually pick the backend.  
>      Please avoid doing this (so that people using dconf can use eog with it).

Ah yes, that's because we were still depending on the desktop lockdown keys which had no settings schema that time and I wanted to avoid splitting the settings.

 
>   2) You mentioned 'old gconf key names' but I see no examples of key names
> that
>      do not satisfy the GSettings naming requirements.  Was this fixed already?

Yes, I started preparing the necessary changes when lucasr had problems rolling 2.30.3 due to them and shortly after fredp opened bug 621370... :)

>      The one thing I notice is that you have some paths containing '_'.  This
> is
>      not wrong, but strange, since your keys all use '-' now.

I guess you mean the "full_screen" path. I kept it to make things not too complicated with GConf due to the renaming assuming it wouldn't carry over to dconf later as the new key is org.gnome.eog.fullscreen.

> 
>   3) The 'transparency' key in your schema could take advantage of the enums 
>      support in GSettings.

Yup, I know another one which could do so too. ;)
Enum support wasn't in GSettings yet when I started the migration. I'll take a look at it.
> 
> Thanks for the porting effort :)

Thanks for taking a look. :)
Comment 6 Felix Riemann 2010-07-28 20:18:44 UTC
(In reply to comment #5)
> (In reply to comment #4)
> >   1) There is very little reason to use setenv() to manually pick the backend.  
> >      Please avoid doing this (so that people using dconf can use eog with it).
> 
> Ah yes, that's because we were still depending on the desktop lockdown keys
> which had no settings schema that time and I wanted to avoid splitting the
> settings.

Lame excuse and it was in the way to use enums in GSetting. So, we don't do it anymore. Also added a file for gsettings-data-convert.
Comment 7 Felix Riemann 2010-07-28 21:12:31 UTC
(In reply to comment #4)
> 
>   3) The 'transparency' key in your schema could take advantage of the enums 
>      support in GSettings.

Done! :)
Comment 8 Felix Riemann 2010-11-20 13:31:30 UTC
Just did the rest:

commit 99f8997a71a6fecd70512432eb3c481d0dc34d8b
Author: Felix Riemann <>
Date:   Sat Nov 20 14:11:15 2010 +0100

    Drop GConf dependency
    
    Concludes the GSettings migration. Closes bug 620121.

commit 653cf389ef92241aa2a66d04b3dad71eeacd4bf3
Author: Felix Riemann <>
Date:   Sat Nov 20 14:03:45 2010 +0100

    Convert lockdown settings from GConf to GSettings
    
    Part of bug 620121.

commit 9bc346bc624c7fde7c3cd878b9f35cb65795bb41
Author: Felix Riemann <>
Date:   Sat Nov 20 13:07:14 2010 +0100

    Convert background image setting fro GConf to GSettings
    
    Adds dependency on gsettings-desktop-schemas package.
    Part of bug 620121.

So, I think we are done here (actually there's a plugin in eog-plugins that needs to be converted as well, but as it is likely needing a rework for the hopefully coming plugin API change...). :)

---
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.