Opened 8 years ago
Last modified 14 months ago
#10029 new task
Support XDG dir structure
| Reported by: | salinasv | Owned by: | EionRobb |
|---|---|---|---|
| Milestone: | 3.0.0 | Component: | libpurple |
| Version: | Keywords: | XDG 3.0.0 | |
| Cc: | elreydetodo |
Description
Add support for XDG dir structure. If there is a .purple, use it, if there is not, create and use a XDG based structure.
Change History (21)
comment:1 Changed 8 years ago by salinasv
- Milestone set to 3.0.0
comment:2 follow-up: ↓ 3 Changed 6 years ago by hobarrera
comment:3 in reply to: ↑ 2 Changed 6 years ago by hobarrera
Ooops, I was not aware WikiFormatting was necessary for line jumps, and I can't edit the previous comment;
As a note for whoever implements this, this requires moving:
certificates/ -> $XDG_CACHE_HOME/purple/certificates/
icons/ -> $XDG_CACHE_HOME/purple/icons/
logs/ -> $XDG_DATA_HOME/purple/logs
smileys/ -> $XDG_DATA_HOME/purple/smileys
blist.xml -> $XDG_DATA_HOME/purple/blist.xml
xmpp-caps.xml -> $XDG_DATA_HOME/purple/xmpp-caps.xml
Everything else already in .purple should move into $XDG_CONFIG_HOME/purple
The default fallbacks (in no enviroment variable are set) are:
$XDG_CACHE_HOME -> $HOME/.cache
$XDG_CONFIG_HOME -> $HOME/.config
$XDG_DATA_HOME -> $HOME/.local/share
I hope this helps, here's the spec in case you prefer to read it:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html[[BR]]
Cheers!
comment:4 Changed 6 years ago by darkrain42
xmpp-caps.xml is cache, not data. And blist.xml is debatably config, since it contains per-buddy configuration details (as well as the details of chat rooms)
Is there a description of what exactly "data" is, because frankly, the specification doesn't say.
comment:5 Changed 6 years ago by hobarrera
It doesn't actually specify, but I guess if something is not config nor cache, it should inevitably be considered "data files".
blist.xml is really a mixture of cache and config. Maybe it should be split up into two files: one for server-provided data (nicknames, etc), one for locally user-configured data. The former is expendable, the latter is not.
comment:6 Changed 5 years ago by faispasierch
- ping
comment:7 Changed 5 years ago by eheintzmann
What is planned about Freedesktop.org Base Directory specification for Pidgin?
According to XDG Base directory specification, Pidgin 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 @APPNAME@ 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.
comment:8 Changed 5 years ago by salinasv
Yes, we are aware of that and I agree with you.
The problem here is that we need some developer time to get it done. We must get a *good* split schema, our accounts.xml have mixed data as well as other files. Also, we should be able to a)migrate the actual .purple to XDG and b)decide if we want to support .purple *and* XDG.
I was planning to do it but now I have a full-time job and I find it hard to find the time to do it.
As always, patches welcome.
comment:9 Changed 5 years ago by rahulsundaram
I am working on a patch right now and I will post the link or attach the patches when I am done. I don't about how you want the schema to be split so I will attempt only to create new directories on fresh launch and migrate the existing data automatically if needed.
comment:10 Changed 5 years ago by rahulsundaram
Here is a first crack at it
http://sundaram.fedorapeople.org/pidgin-xdg-base-dir-support.patch
creates new profile in .local/share/purple and certs and icons in .cache/purple move existing profile if one exists to the above directories autoaccept plugin will save data in .local/share/purple
certs move isn't complete, prefs.xml needs to be moved to .config/purple and xmpp-caps.xml to be moved to .cache/purple. that would need some refactoring of the purple write and read file functions to take a location instead of assuming purple_home to be the standard location for all the files.
I will continue to work on it but I will happy to take in some feedback at this point.
comment:11 Changed 5 years ago by salinasv
I am glad to see a patch for this feature. I have not had any time to get to it.
I quickly saw your patch and it looks like you only move the files as they are to the XDG comliance dirs. The issue with this feature is that the some of the files (blist.xml and accounts.xml especially) do have information that belongs to XDG_DATA, XDG_CACHE and also XDG_CONFIG, so it is not "clean" to just move the files to the new dir.
I setup a wiki page to start the discussion on which feature must go to which dir. XDG_dirs
I am also sending an email to devel.
comment:12 Changed 5 years ago by rahulsundaram
Yes, I noted that problem in comment 9 and doing the split in configuration is cleaner but more than I am willing to take on with a entirely unfamiliar codebase. I am a happy user of Pidgin and I was just trying motivated to prod at this issue a bit. Happy to see some progress. Thanks!
comment:13 Changed 4 years ago by rekkanoryo
- Owner changed from rekkanoryo to EionRobb
comment:14 Changed 4 years ago by elrond
I think, it is a good idea to start moving some files over. It does not hurt to keep some in .purple until it is known where to put the things.
From looking at the wiki, the most obvious ones are:
| certificates/ | * | XDG_DATA |
| icons/ | * | XDG_CACHE |
| logs/ | * | XDG_DATA |
| xmpp-caps.xml | * | ? XDG_CACHE |
| pounces.xml | * | ? XDG_DATA |
The last two entries are my personal guess deviating from the wiki.
comment:15 Changed 3 years ago by rahulsundaram
Any update on this?
comment:16 Changed 3 years ago by salinasv
It looks like no developer have had time to get to this. I have been out of time last years so I can't promise to take a look soon but I have this on my radar, FWIW.
comment:17 Changed 2 years ago by salinasv
- Component changed from unclassified to libpurple
comment:18 Changed 16 months ago by Robby
This is being worked on: https://bitbucket.org/pidgin/main/pull-requests/138/migrate-to-xdg-dirs-part-1/
comment:19 Changed 15 months ago by qarkai
I think that accounts.xml splitting should be following:
| protocol | XDG_DATA |
| name | XDG_DATA |
| password | XDG_DATA |
| statuses | XDG_CONFIG |
| userinfo | XDG_CACHE |
| settings | XDG_CONFIG |
| proxy | XDG_CONFIG |
| current_error | XDG_CONFIG |
As far as I understand, purple gets and sets userinfo from server, that is why it should go to XDG_CACHE.
Difference between XDG_CONFIG and XDG_DATA in my opinion is that config info has default value. Obviously, account id (protocol+name) and password doesn't have default values. Of course account id will be copied to XDG_CONFIG in order to bind account and it's settings.
comment:20 follow-up: ↓ 21 Changed 14 months ago by sergem
Please, don't do this! Please-please-please! Don't split files among multiple dirs! It makes backups/restores/cleanup/sync harder. It also adds a lot of confusion: in this bugreport there're SEVEN different ways to place the files, you can't call it easy and obvious, can you? And it adds no other advantages. Then why making things more complex at all?
[long explanation follows]
There's a major difference between root filesystem and home files: root filesystem is managed by the package manager. You can easily tell where any app has its files, and for any file find which app it belongs to. But you can't do that for home dir. So if you have some versions conflict, or pidgin crashes because one of the files got corrupt, or you want to clear the logs - you can't just reinstall the app to clean those files, you have to search through your entire home. It's easy when all files are in one ~/.purple dir, but it's many times harder if you put them in different dirs.
XDG basedir spec is not about that. It's a base for other standards describing SHARED files, used by MULTIPLE independent desktop environment apps.
A long long time ago there're multiple desktop environments: gnome, kde, rox... Each of them had autostarts and a main menu - a button that you can press and see what apps you can run, their names, icons, etc. So each app that wanted to appear in the menu had to write itself somewhere. Requiring every app to know formats of .gnome/apps, .kde/share/apps and .rox/... was not a good idea, so devs came together and created common standards. They wrote autostart-spec, desktop-entry-spec, icon-theme-spec, menu-spec, mime-apps-spec, shared-mime-info-spec...
Those specs describe EXACT FORMAT of each file and mention the directory to place it in great details. So for each directory it'd say "use this, if it doesn't exist use this, if that doesn't exist use this, if it doesn't exist create it with those permissions, read defaults from that dir, write them to this dir..." That's a lot of text to repeat in each spec. To make it easier they created a common BASE spec for those dirs, and referenced it in other standards. They even described how exactly it should be referenced ("Referencing this specification" section).
That's all. "Basedir spec" is just a common base specification to reference in other STANDARDS for SHARED files. E.g. to add itself to Autostarts, pidgin must put its desktop file (as desktop-entry-spec says) into "autostarts" in ~/.config (as autostart-spec says) or create it with permissions 0700 if it does not exist (as basedir-spec says). If we were talking with gajim and jitsi devs we could write a common standard of accounts and logs storage and reference basedir-spec in our standard. But nothing in those standards expects pidgin to put all its private files into those dirs. Gnome/kde devs wrote those standards, but they have not placed ALL files there, just the shared ones, why pidgin should be any different?
PS: If you're still not convinced, XDG basedir-spec says "If $XDG_CONFIG_DIRS is either not set or empty, a value equal to /etc/xdg should be used", but you're not going to use /etc/xdg/purple, are you?
PPS: What you may really want is to reduce number of dot-directories in your home. If you're just looking for a "standard" place to move private undocumented files somewhere - there's none. But if you really want to - move them all together into ~/.config/ and officially document it. That's still an abuse of XDG standards, but it's not as bad as splitting files across multiple dirs. Or just use PURPLEHOME env or -c option. Just don't scatter files across the home directory, please! It adds problems and confusions, but has no advantages.
comment:21 in reply to: ↑ 20 Changed 14 months ago by qarkai
Replying to sergem:
Gnome/kde devs wrote those standards, but they have not placed ALL files there, just the shared ones, why pidgin should be any different?
It looks like GNOME patched a lot of their apps: https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders
PS: If you're still not convinced, XDG basedir-spec says "If $XDG_CONFIG_DIRS is either not set or empty, a value equal to /etc/xdg should be used", but you're not going to use /etc/xdg/purple, are you?
No, it should be $HOME/.config/purple: "$XDG_CONFIG_HOME defines the base directory relative to which user specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used." $XDG_CONFIG_DIRS according to basedir-spec is an addition to the $XDG_CONFIG_HOME.
PPS: What you may really want is to reduce number of dot-directories in your home. If you're just looking for a "standard" place to move private undocumented files somewhere - there's none. But if you really want to - move them all together into ~/.config/ and officially document it. That's still an abuse of XDG standards, but it's not as bad as splitting files across multiple dirs. Or just use PURPLEHOME env or -c option. Just don't scatter files across the home directory, please! It adds problems and confusions, but has no advantages.
There is another opinion: https://ploum.net/184-cleaning-user-preferences-keeping-user-data/ https://ploum.net/207-modify-your-application-to-use-xdg-folders/




As a note for whoever implements this, this requires moving:
certificates/ -> $XDG_CACHE_HOME/purple/certificates/ icons/ -> $XDG_CACHE_HOME/purple/icons/
logs/ -> $XDG_DATA_HOME/purple/logs smileys/ -> $XDG_DATA_HOME/purple/smileys blist.xml -> $XDG_DATA_HOME/purple/blist.xml xmpp-caps.xml -> $XDG_DATA_HOME/purple/xmpp-caps.xml
Everything else already in .purple should move into $XDG_CONFIG_HOME/purple
The default fallbacks (in no enviroment variable are set) are: $XDG_CACHE_HOME -> $HOME/.cache $XDG_CONFIG_HOME -> $HOME/.config $XDG_DATA_HOME -> $HOME/.local/share
I hope this helps, here's the spec in case you prefer to read it: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html Cheers!