Rework of GConf settings
From Evolution
Contents |
Rework of GConf settings
This document is intended at describing why gconf settings of evolution should be rearranged and how it should look like. It is still a draft and only represent my view of how evolution GConf settings should look like. --EvaSDK 14:28, 9 October 2007 (MDT)
The Why
Currently evolution has its own XML parsing API which is mostly wrapped around libxml2. This is probably something that we should get rid of because there is no point in having 2 ways to do XML in evolution.
The current use of the internal XML API is :
- XML configuration blurbs parsing (from GConf or files)
- Left panel tree (unsure)
So yes, evolution puts XML into GConf and does it's own parsing on top of this (considering GConf is stored in XML files by default, I'll let you imagine how much braindead the situation is). Evolution has configuration files under ~/.evolution and in GConf and now you can feel there is something really wrong don't you ? Evolution also has, partly due to those XML blurbs and configuration files, poor lockdown capability (bug #?).
There is two way to fix this as often. Go back to the drawing board or fix everything incrementally. Given how bloated the current GConf settings looks with plugins putting their keys everywhere, etc, I'd vote for the drawing board.
The How
- Rework the layout of the GConf settings (clearly seperate eplugins, components, properly nest what has to be nested and don't nest what doesn't need to be nested, etc)
- Kill the XML parsing. There is no reason to do this nowadays (I have no background to say there never was), so let's just put everything in flat key:value GConf settings.
- Kill XML config files. Unless there is a very very good reason to not put a configuration file into GConf, it should die hence (hopefully) reducing internal XML API use and increasing lockdown possibilities
- optional: move the simple xml parsing to glib parser instead of libxml ?
An example
evolution
addressbook
mail
account01 <-- yes that implies pregenerated GConf schemas entries up until 99 (but it's not as bad as the current stuff)
account02
account-name <-- These are the properties of an EAccount as of rev9032
account-enabled
identity-name
identity-addr
identity-reply-to
identity-organization
signature-uid
source-save-passwd
source-keep-on-server
source-auto-check
source-auto-check-timeout
source-url
transport-save-passwd
transport-url
draft-folder
sent-folder
auto-cc-always
auto-cc
auto-bcc-always
auto-bcc
receipt-policy
pgp-encrypt-to-self
pgp-always-trust
pgp-always-sign
pgp-no-imip-sign
smime-sign-default
smime-encrypt-default
smime-encrypt-to-self
parent-uid
[...]
accountNN
calendar
memos
plugins
plugin1 <-- settings of this particular plugin goes here
setting1_plugin1
setting2_plugin1
enabled
hidden <-- shamelessly inspired by how rhythmbox does it
[...]
pluginN
tasks
Discussion
I wouldn't use pluginN as a key as you can't provide meaningful schemas for that. Couldn't the plugin itself ship the schema and then use evolution/plugins/name_of_my_plugin itself? --Muelli 06:46, 13 August 2008 (MDT)
Actually yes, the plugins can ship shemas and it would indeed be better to do things that way (that's probably what I wanted to say in the first place but I can't remember now :p). --EvaSDK 01:09, 14 August 2008 (MDT)
Notes
- It'll obviously require a migration path.
- It might break a lot of stuff for a while.
- This way of doing things can take great advantage of libgconf-bridge
- mbarnes and jeff suggested that after all, account settings might be better hosted oustide of GConf
- having proper storage for settings would ease the work of the backup plugin in selecting appropriate file/folders to backup
