Open Bug 735285 Opened 8 years ago Updated 16 days ago

Support for the Freedesktop.org XDG Base Directory Specification in Thunderbird

Categories

(Thunderbird :: Preferences, enhancement)

10 Branch
All
Linux
enhancement
Not set

Tracking

(Not tracked)

UNCONFIRMED

People

(Reporter: psychonaut, Unassigned)

References

(Depends on 1 open bug, )

Details

(Whiteboard: [any fix would come through core bug 259356])

Currently Thunderbird stores its user application data (preferences, cache, etc.) in ~/.thunderbird, thus cluttering the user's home directory with yet another arbitrarily chosen hidden directory.  Thunderbird should instead support the Freedesktop.org XDG Base Directory Specification <http://freedesktop.org/wiki/Specifications/basedir-spec> under GNU/Linux.

The same problem is the subject of Bug 247973, though the proposed resolution is less preferable.

Similar requests have already been made for Firefox (Bug 259356) and SeaMonkey (Bug 726939).
Depends on: 259356
Summary: Support for the Freedesktop.org XDG Base Directory Specification → Support for the Freedesktop.org XDG Base Directory Specification in Thunderbird
* ping
According to XDG Base directory specification, Thunderbird@ should not have its own folder anymore:
User data should go into $XDG_DATA_HOME (which default to ~/.local/share),
user preferences should go into $XDG_CONFIG_HOME (which default to ~/.config)
and cached data should go to $XDG_CACHE_HOME (which default to ~/.cache).
More details at :
http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders

Full specification can be found at: 
http://standards.freedesktop.org/basedir-spec/latest/

The Freedesktop.org XDG base directory specification have good de facto adoption.
It has been adopted by:
- GNOME ( https://live.gnome.org/GnomeGoals/XDGConfigFolders )
- GTK+ ( https://bugzilla.gnome.org/show_bug.cgi?id=646631 )
- KDE ( http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy#Freedesktop.org_and_Standard_Directories )
- QT ( http://harmattan-dev.nokia.com/docs/library/html/qt4/qsettings.html#setPath )
- XFCE ( http://docs.xfce.org/xfce/xfce4-session/advanced in Files and Environment Variables )
- LXDE
- Razor-qt
- VLC ( https://trac.videolan.org/vlc/ticket/1267 )
- GStreamer ( https://bugzilla.gnome.org/show_bug.cgi?id=518597 )
- Chrome ( http://code.google.com/p/chromium/issues/detail?id=16976 )
- many more upstream applications
- Ubuntu ( http://brainstorm.ubuntu.com/idea/6557/ & http://packages.ubuntu.com/fr/source/precise/libxdg-basedir )
- Debian ( http://packages.debian.org/squeeze/libxdg-basedir1 )
- Red Hat
- Fedora
- Suse
- many more distributions

I think that Thunderbird should use same locations than the vast majority of Desktop environment and applications.


There are real advantages of following this specification :
- a lot less cluttered $HOME
- Make backups a lot more safer and easier.
  Backuping your $XDG_DATA_HOME along with your files is enough 
  (or just excluding $XDG_CACHE_HOME)
- 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.
Pinging. Over 4 years later, this bug should be confirmed.
Когда же эти пидары эту паеботу исправят? Неужели так трудно слодовать по спецификациям???
Please close this "bug" as wontfix. Having all Thunderbird data in one directory (.thunderbird) makes it portable across operating systems. I can migrate Thunderbird users between Linux, Windows and BSD by simply copying their .thunderbird folder to another computer/OS. Separating the contents into separate folders does nothing to help the user and makes work harder for administrators.

This means the above points raised by Eric are incorrect as splitting the folder makes for _less_ flexibility and less portability and makes it harder to backup _just_ the Thunderbird profile. Cluttering $HOME does not matter because the folder is hidden so it's invisible to the end user anyway.
(In reply to slicer69 from comment #5)
> Please close this "bug" as wontfix. Having all Thunderbird data in one
> directory (.thunderbird) makes it portable across operating systems. I can
> migrate Thunderbird users between Linux, Windows and BSD by simply copying
> their .thunderbird folder to another computer/OS. Separating the contents
> into separate folders does nothing to help the user and makes work harder
> for administrators.

Please read the XDG Base Directory Specification. It is not Linux specific.

Additionally, storing everything in $XDG_DATA_HOME is a valid approach if people really want it centralized, but using different folders means you can choose to store the application configs AND/OR application data AND/OR cache, depending on what you want.

As far as your own personal usecase goes, it's just two more automated symlinks/copies if you want everything.

> This means the above points raised by Eric are incorrect as splitting the
> folder makes for _less_ flexibility and less portability and makes it harder
> to backup _just_ the Thunderbird profile. Cluttering $HOME does not matter
> because the folder is hidden so it's invisible to the end user anyway.

If you just want the profile, you'd just copy $XDG_CONFIG_HOME/thunderbird and call it a day.
I'm tempted to just dupe this to bug 259356. Thunderbird isn't going to do anything special here - we're just tagging along to what core might implement there. I doubt Thunderbird would need to do anything major to get the functionality if it would exist in core.
Whiteboard: [any fix would come through core bug 259356]
(In reply to Magnus Melin [:mkmelin] from comment #7)
> I'm tempted to just dupe this to bug 259356. Thunderbird isn't going to do
> anything special here - we're just tagging along to what core might
> implement there. I doubt Thunderbird would need to do anything major to get
> the functionality if it would exist in core.

Yeah, but I'm guessing that the fix to core won't automatically apply to all dependent products.  That is, once the core functionality is there, the respective product developers will still need to write some (small amount of) code to make use of it.  So I suspect it's best to leave this bug open as a dependent of Bug 259356.  The fix to that bug will ping this one, which will be the signal to start implementing this one.
You need to log in before you can comment on or make changes to this bug.