GNOME Bugzilla – Bug 622401
Migrate to GSettings
Last modified: 2011-08-03 08:13:29 UTC
Migrating from GConf to GSettings is an official GNOME goal now, so we probably should get on this. http://live.gnome.org/GnomeGoals/GSettingsMigration
Somehow during the migration we also need to bring the agent settings over to gnome-keyring... since that's the where the gpg-agent is going to live.
(In reply to comment #1) > Somehow during the migration we also need to bring the agent settings over to > gnome-keyring... since that's the where the gpg-agent is going to live. Let's annotate these things in the list of things to talk about at guadec :)
Yes, I agree. Is there time to do this correctly rather than rushed? Because as others have brought up, I'm concerned that the crypto preferences on the desktop are rather unified rather than having one capplet gnome-keyring, another capplet for seahorse, another for seahorse-plugins, and then of course seahorse itself (which is a manager type application).
Stef and I discussed about it in GUADEC. A first draft of the changes is here: http://spreadsheets.google.com/ccc?key=0Ar1ht11q4k3tdGJjSTQza0lYTm9MaDBnN0RtQzZlNUE&hl=en&pli=1#gid=0 Comments are welcome
Right link: http://spreadsheets.google.com/pub?key=0Ar1ht11q4k3tdGJjSTQza0lYTm9MaDBnN0RtQzZlNUE&authkey=CL6drbwK&hl=en&single=true&gid=0&output=html
Cool. Looks good. If there end up being some questions which delay migrating seahorse-plugins, I would suggest going forward with the other stuff anyway.
If nobody disagrees I will start working on it next week
Pablo, Those look good to me too. I'll try to find some time to sort the plugins keys. I'm not sure what the forward path is for the applet anyway because gnome-shell doesn't have the concept of applets.
Pablo, in org.gnome.crypto.cache it turns out that combining the method and ttl are isn't necessarily the best all round. I know I suggested it, but now while implementing in gnome-keyring it turns out to be lousy. Because we want to be able to store the ttl (seconds until timeout) even if the method doesn't use the ttl (such as storing in the gnome-keyring). This is a UI issue, so that when the user switches the method back to something that uses the ttl the last chosen ttl is still there.
(In reply to comment #9) > Pablo, in org.gnome.crypto.cache it turns out that combining the method and ttl > are isn't necessarily the best all round. I know I suggested it, but now while > implementing in gnome-keyring it turns out to be lousy. > > Because we want to be able to store the ttl (seconds until timeout) even if the > method doesn't use the ttl (such as storing in the gnome-keyring). This is a UI > issue, so that when the user switches the method back to something that uses > the ttl the last chosen ttl is still there. Sorry Stef, but I haven't understood the problem. But anyways, do you have any better idea?
Sorry if I wasn't clear. What I'm suggesting is to keep gpg-cache-method and gpg-cache-ttl separate, rather than combining the values like 'idle:10' or 'timeout:20'. Instead the method (like 'timeout', 'idle' etc.) would be in the gpg-cache-method setting, and the ttl (like '10', '20' etc.) would be in gpg-cache-ttl.
I've done the gnome-keyring migration and added these schemas to gnome-keyring: org.gnome.crypto.cache org.gnome.crypto.pgp BTW, Pablo it seems to make more sense if the org.gnome.crypto stuff would instead be in org.gnome.crypto.pgp since it's all PGP related. You can check these out on the gsettings-migration branch of gnome-keyring on git.gnome.org. If it all looks good, then I'll merge with master. Thanks for taking a look.
I've merged gsettings-migration into gnome-keyring master ahead of the 2.31.90 release next week.
Hello Stef, Can we close this, then?
Sadly seahorse and seahorse-plugins still need to be migrated.
Created attachment 192752 [details] [review] Update seahorse to gsettings The branch is here: http://cgit.collabora.com/git/user/stefw/seahorse.git/log/?h=gsettings
Created attachment 192801 [details] [review] Port libcrypt to gsettings Branch is here: http://cgit.collabora.com/git/user/stefw/libcryptui.git/log/?h=gsettings
Made some more fixes to the seahorse gsettings branch: http://cgit.collabora.com/git/user/stefw/seahorse.git/log/?h=gsettings
Merged into seahorse and libcryptui. Both these are now ported to gsettings.
Can we close this bug then?
Yup. Let's do that.