Bug 2037 - Claws Mail does not use XDG Folders
Summary: Claws Mail does not use XDG Folders
Status: NEW
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Other (show other bugs)
Version: 3.7.3
Hardware: PC Linux
: P3 enhancement
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2009-11-03 18:47 UTC by Andrew
Modified: 2020-12-13 16:24 UTC (History)
3 users (show)

See Also:


Attachments
The new arrangement of the files/folders (1.27 KB, text/plain)
2009-11-03 18:48 UTC, Andrew
no flags Details

Description Andrew 2009-11-03 18:47:55 UTC
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).


--
Andrew
Comment 1 Andrew 2009-11-03 18:48:30 UTC
Created attachment 748 [details]
The new arrangement of the files/folders
Comment 2 Ricardo Mones 2009-11-06 00:30:18 UTC
> 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).
Comment 3 Andrew 2009-11-06 06:40:38 UTC
From ploum.frimouvy.org:
    * 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?
Comment 4 Colin Leroy 2009-11-06 07:59:13 UTC
> 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 :-)
Marking enhancement.
Comment 5 Holger Berndt 2009-11-06 14:27:17 UTC
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.
Comment 6 Andrew 2009-11-06 17:38:24 UTC
Sure, I understand this will not be immediate :-)
Comment 7 Ricardo Mones 2009-11-08 02:45:00 UTC
>    * 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.
Comment 8 Elrond 2013-04-26 13:27:55 UTC
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.
Comment 9 Olivier Fabre 2013-05-16 15:16:58 UTC
What about at least moving ~/.claws-mail to ~/.config/claws-mail?
Comment 10 claws-mail-bugs 2020-12-12 22:47:31 UTC
> * a lot less cluttered $HOME (my mother will not cry anymore when the gtk file selector randomly choose to display hidden folders)

Bingo.  I'm new to using Claws-Mail outside of Maemo, and one immediate annoyance is compulsory pollution in $HOME.

I spent some time meticulously inspecting the config options and searching the manual for a way to at least choose a different root folder.  I thought I had to be overlooking something until I found this bug report.  It's baffling that someone would hard-code the path of the email storage -- which can get quite large.

If this were a launchpad bug report, I'd be adding a vote to the flames for sure.

Untested workaround:

perhaps launch Claws Mail this way: `HOME=$XDG_DATA_HOME claws-mail`
Comment 11 Paul 2020-12-13 10:20:13 UTC
(In reply to juhuseq from comment #10)
> Bingo.  I'm new to using Claws-Mail outside of Maemo, and one immediate 
> annoyance is compulsory pollution in $HOME.

It is not compulsory.

> I spent some time meticulously inspecting the config options and 
> searching the manual for a way to at least choose a different root 
> folder.  I thought I had to be overlooking something until I found 
> this bug report.  It's baffling that someone would hard-code the 
> path of the email storage -- which can get quite large.

Define "meticulous"

Start with `claws-mail --alternate-config-dir [DIR]` to point to an alternate location for the config directory (default is ~/.claws-mail/).

When adding an MH mailbox it can be wherever you want it to (default is ~/Mail/).
Comment 12 claws-mail-bugs 2020-12-13 16:24:49 UTC
Ah, sorry Paul, you're correct.  I just realized that the first prompt to enter the box name is acually a chance to enter a full pathname, and I was quite the opposite of meticulous at that moment.  If the field had been pre-populated with "$HOME/Mail" (and not just "Mail") it would have been more clear.  

Then when I saw that there is no move mailbox option and "Move folder.." is grayed out, it further reinforced my misunderstanding that the mailbox must be in $HOME.

Note You need to log in before you can comment on or make changes to this bug.