Claws Mail doesn't use the XDG config, data or cache folders, but instead uses ~/claws-mail.
This should be avoided and instead the XDG folders used. I am no C programmer, however a sample piece of code for getting the XDG folder variable is available here http://launchpadlibrarian.net/12617555/xdg_pref.patch
The way that the folders/files need to be distributed is attached so it can be updated (please correct me anywhere that I am wrong).
Created attachment 748 [details]
The new arrangement of the files/folders
> This should be avoided and instead the XDG folders used.
Why? What's not working with current setup?
This is not a bug at all, at most an enhancement request.
> The way that the folders/files need to be distributed is attached
So, again, what's the huge benefit achieved with that huge reorganisation?
It's huge not only by the number of items rearranged but more by the number of coding and testing required to have it done correctly (as it should be transparent to current users to be done properly).
* a lot less cluttered $HOME (my mother will not cry anymore when the gtk file selector randomly choose to display hidden folders)
* Make backups a lot more safer and easier. (you know that backuping your $XDG_DATA_HOME along with your files is enough)
* A lot easier to reset a default configuration if you want/need it (and without any risk to loose informations). Even for the software itself could choose to reset $XDG_CONFIG_HOME if needed.
* Avoid some strange bugs that happens because you had a old version of some configuration file
* A lot more of flexibility and portability because no path are hardcoded. You use the XDG library that does the job for you. If you don't want the dependency, implementing the XDG specification is only a few lines of code.
The problem : I like to keep as near-default configuration for my Gnome desktop. Every 6 months, I simply format my root partition and reinstall Ubuntu with all the packages I need (it's even quicker than a dist-upgrade). Of course, I keep my /home partition.
And this /home partition is now a complete mess, filled with hidden .folders from every application I ever tried. Because I've sometimes played with experimental software, those .folders are filled with craps. Go straight for an example : I cannot use Compiz. I've tried to delete all related hidden folders and files, the compiz configuration is still unusable thanks to some well hidden breakage, a probable inheritance of the Beryl times. I'm not a fan of Compiz but it makes me sad to know that there's something ugly somewhere on my computer.
Unfortunately, this problem is deeper than previously thought. Sometimes, on a fresh install I have bugs not reproducible anywhere else. Sometimes, the maintener of a package feel the need to push a new sensible default. Also, how the hell can we do a correct backup without too much overhead ?
Now I know this would be a lot of work, but then isn't every bug/enhancement. If you say you have to change the locations in a lot of files, surely isn't this a good time to write to ONE place where all the locations are and then just reference them in subsequent files?
> Now I know this would be a lot of work, but then isn't every bug/enhancement.
> If you say you have to change the locations in a lot of files, surely isn't
> this a good time to write to ONE place where all the locations are and then
> just reference them in subsequent files?
Hehe, that's funny, thanks :-)
Ricardo said "number of coding and testing required to have it done correctly"
Not number of files. Of course it's all coded in one place right now, as everything is in one place. But Ricardo knows what he speaks about: we already moved the .claws-mail dir when renaming from Sylpheed-Claws, and it was just the equivalent of "mv .sylpheed-claws .claws-mail", and it had to be done correctly.
Reading your attachment (and yes, that's how it should be done), that makes 6 different locations to use for 3 different kind of data. *That* requires a lot of work to
a) move everything to the new place *once*, at startup, transparently, and failing is not an option
b) changing all files that use the C equivalent of open $CONFIG/path/file to open $XDG_DATA_DIR/path/file or $XDG_CONFIG_DIR/path/file or $XDG_CACHE_DIR/path/file (and there i didn't even account for history/backups/logs/certs/imapcache/mimetmp/newscache/tempfolder/tmp directories, that aren't used in the same places).
So, yes, it's very rare that bugs or enhancements require that much work :)
I'm not saying WONTFIX (or it'd be in this state already), just that it's an enhancement, and that given the work it requires, don't expect any deadline :-)
That will for sure break some setups, where people hard-code ~/.claws-mail in their actions or in scripts, or install themes, ring-tones or scripts locally under ~/.claws-mail.
Still, I think it'd be good to follow XDG, especially for cache separation from data/config. People tend to back up their ~/.claws-mail folder, and there's little point to make it hard to omit caches from the backup.
In any case, a change like this is never a trivial, glitch-free transition.
Sure, I understand this will not be immediate :-)
> * a lot less cluttered $HOME (my mother will not cry anymore when the gtk
> file selector randomly choose to display hidden folders)
That sounds like a problem on the gtk file selector... and the solution is is to put them in a .config directory? BTW, what prevents your mother to enter .config and get lost in the horrible mess inside? :)
> * Make backups a lot more safer and easier. (you know that backuping your
> $XDG_DATA_HOME along with your files is enough)
I don't think you want to lose, for example, your account information on a mail program. The split proposed by the XDG proposal may apply for some programs, but not for all.
> * A lot easier to reset a default configuration if you want/need it (and
> without any risk to loose informations). Even for the software itself could
> choose to reset $XDG_CONFIG_HOME if needed.
We call it --alternate-config-dir, and is pretty simple.
> * Avoid some strange bugs that happens because you had a old version of
> some configuration file
Another generic asumption. If you have bugs caused by old configuration files you should either migrate the files or fix your application.
> * A lot more of flexibility and portability because no path are hardcoded.
> You use the XDG library that does the job for you. If you don't want the
> dependency, implementing the XDG specification is only a few lines of code.
You mean only a few lines of code for each involved file... don't you? :)
> The problem : I like to keep as near-default configuration for my Gnome
> desktop. Every 6 months, I simply format my root partition and reinstall Ubuntu
> with all the packages I need (it's even quicker than a dist-upgrade). Of
> course, I keep my /home partition.
I installed Debian Sid 5 years ago (starting from a Woody CD), and only reinstalled it a couple of weeks ago because one of the disks crashed, I have better things to do than reinstall my system.
> And this /home partition is now a complete mess, filled with hidden .folders [...]
You are only swepping the mess under a carpet called .config. That won't prevent such problems from happening again, because the problem is lazy coders which don't care about providing migration paths for existing users, not the location of files in the filesystem.
Anyway I agree with Holger about the cache separation, I think that's an interesting point, as you usually don't want to backup your cache. Anyway should be configurable via configure flag, as others may want it inside config dir.
What about starting in steps with this issue and providing an option to move the caches (imapcache in my case) to a chooseable directory, and one option being "XDG"? That way people can move the cache onto their fast cheap SSD and be happy.
Another reason to move to .config: Some people might have this directory in a auto VCS that creates a new revision for every config change, so that they can go back to any version of their configs. Having to add every ~/.your-app to the VCS by hand is quite annoying. Just having them all nicely in .config is much nicer.
And to experiment with XDG compliant apps is easy: Set the XDG variables and start the app. No need to read lengthy manauls to learn about --config-dir-here, --cache-there.
Wether account config is "config" or "data" is a heavy question. Probably config. Wether folder settings are config or data... I'd say data. It belongs closely to the real data in question. I guess, you guys will choose something useful.
Anyway. My main point is: Why not start with the cache directory?
If anything goes wrong, it only affects the cache.
What about at least moving ~/.claws-mail to ~/.config/claws-mail?