GNOME Bugzilla – Bug 300940
Store adressbooks names in ~/.evolution , not in ~/.gconf
Last modified: 2012-06-04 12:36:56 UTC
I've reinstalled a new OS (Ubuntu Hoary) instead of my old one. It was a choice, but it could be because of a disk crash or something else. I backup regulary my files and the .evolution folders. Nothing else. When restoring, all was perfect for Evolution except that I had only one adressbook ! (personnal) After looking some time, I've find that I simply need to restore ~/.gconf/apps/evolution/addressbook/%gconf.xml Hopefully, I had it ! I think this is a really bad idea and that Evolution must show all adressbook available in his config directory. If I hadn't reinstalled by choice, I would have maybe lost the .gconf folder !!! Other information:
The list of adressbooks is kept in gconf, so I don't think it's possible to move this list in ~/.evolution, unless you store the list in some non-gconf way. I'll let the devels handle this.
Not an addressbook specific issue. from http://go-evolution.org/Evo2.6 " Unified Account Management Information pertaining to groupware accounts (that provide mail, calendaring and addressbook) is split into EAccounts and multiple ESources, making them difficult to manage. User data is also spread over .evolution and .gconf. This needs to be consolidated into a more manageable format. " Moving it to misc.
The value of the key in gconf.xml is itself XML which is not very pretty... Hem.. Perhaps puttings the xml data in a file in .evolution would be enough and not too difficult ?
*** Bug 340640 has been marked as a duplicate of this bug. ***
Another related bug to look at while fixing this is bug #238667
Hmm..bug #238667 asks just the opposite - store in gconf not in ~/.evolution. In the absense of a single policy for configuration storage across all components (sooner we have one, the better) - each component will have to do it the way it feels the best.
Harish > The common point is that users want one clear solution : .evolution or .gconf (I personnaly don't really care). But mixing both is the real bug. I wrote an article about this : http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
This is the expected behaviour : http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
I agree with Harish that people just want one clear solution; I also agree that the standard should be followed, although it contemplates two directories, one for configuration and one for data. As much as I hate to go through an re-config my desktop after a reinstall, I think Lionel's definition of what is config and what is data is a good place to draw the line: if you can't afford to loose it, it's an user data. If a usable default exist, it's a preference. That might be a little easier said than implemented, or perhaps by that definition most of what Evolution stores is data, not configuration, so perhaps I would write the distinction this way: If a piece of information is a choice in which all users must choose from the same finite set of options, it's configuration. If I have to type it in, and it's unique to me, it's data.
Sounds to me like not storing actual *data* in gconf and simply dumping it somewhere in .evolution would do the job. I remember reading somewhere that gconf is *clearly not* intended to hold any data, it is only for basic settings. What's missing for this bug to be fixed, or at least confirmed?
I must add that this bug is definitely *not* an enhancement. It's a real bug. The day you restore from a backup after a disk corruption to discover that all your address book is lost (because you didn't backuped .gconf), you don't feel it's an "enhancement". You scream, you cry and hate Evolution, that's it.
Removing myself from the cc list as I have switched to Thunderbird.
Also see bug 548596
The account-mgmt branch will address this. I'm hoping to finish it for Evolution 3.6.
This is fixed now by the account-mgmt branch merge for Evolution 3.5.3. Account data is now stored as plain-text files in $HOME/.config/evolution/sources. More details: http://mbarnes.livejournal.com/4631.html