GNOME Bugzilla – Bug 635379
Port to GSettings
Last modified: 2013-09-14 16:55:38 UTC
http://live.gnome.org/GnomeGoals/GSettingsMigration $ git grep gconf-c addressbook/backends/groupwise/create-account.c:#include <gconf/gconf-client.h> calendar/backends/caldav/e-cal-backend-caldav.c:#include <gconf/gconf-client.h> calendar/backends/contacts/e-cal-backend-contacts.c:#include <gconf/gconf-client calendar/backends/http/e-cal-backend-http.c:#include <gconf/gconf-client.h> libebackend/e-offline-listener.c:#include <gconf/gconf-client.h> libedataserver/e-account-list.h:#include <gconf/gconf-client.h> libedataserver/e-account.c:#include <gconf/gconf-client.h> libedataserver/e-categories.c:#include <gconf/gconf-client.h> libedataserver/e-proxy.c:#include <gconf/gconf-client.h> libedataserver/e-source-list.h:#include <gconf/gconf-client.h> servers/groupwise/create-account.c:#include <gconf/gconf-client.h>
Working on this but it's not a straight-forward port. See my recent posts on evolution-hackers@gnome.org about redesigning account management.
Thanks for the info Matthew, for the record: http://mail.gnome.org/archives/evolution-hackers/2010-November/msg00013.html
I'm now targetting my account management rewrite for 3.1, so it looks like we'll still be using GConf for 3.0.
[Still blocking metabug 622558, restoring.]
(In reply to comment #3) > it looks like we'll still be using GConf for 3.0. Adjusting GNOME Target field.
This will not happen for 3.2, but for 3.4. Also see https://live.gnome.org/Evolution/Planning34
Update https://mail.gnome.org/archives/evolution-hackers/2011-November/msg00034.html
Hi, I just want to ask in which release do you plan to finish the port to GSettings. I'm mainly concerned about replacement of those e_*_gconf() functions (ESourceList) with their gsettings equivalent. These are used in ekiga, planner and gnome-phone-manager (phonemgr). Regards Marek
The remaining GConf keys in use with embedded XML blobs aren't bound for GSettings. They will instead be converted to a brand new file format and stored in ~/.config/evolution/sources. I have a branch in progress to implement this ("account-mgmt") but it's taking a long time to complete. There will be major changes to libedataserver -- the new API can be previewed here: http://mbarnes.fedorapeople.org/account-mgmt/docs/libedataserver/ Target release has slipped several times already, but is currently 3.6. (Leaving plenty of time in 3.5 to help migrate other projects.)
Just wondering: Is there a specific reason why evolution still ships all the old, now unused gconf schemas?
Not really. Someone just needs to clean them up.
Does anybody work on finishing this / will this really happen for 3.4 ("GNOME Target" field) or shall this be postponed to 3.6? How dangerous is it to have it half-migrated for 3.4, as that seems to be the case when grep'ing for gconf in e-d-s?
We'll be using both GSettings and GConf for 3.4. I was going to just leave the GConf schemas alone until we're 100% migrated.
Thanks for clarifying. Bumping the target.
*** Bug 227451 has been marked as a duplicate of this bug. ***
So this is FIXED?
Almost.
I port remaining bits from GConf to GSettings in eds by two commits, one in eds, the other in evo. I made ENameSelecterEntry changes the way Matthew suggested on IRC and it looks neat. Created commit 8079043 in eds master (3.5.3+) Created commit e8dc7d8 in evo master (3.5.3+)