replace ~/.mixxx folder with XDG config folders

[mixxxbot]

Reported by: daschuer Date: 2015-06-09T06:36:30Z Status: Triaged Importance: Wishlist Launchpad Issue: lp1463273 Tags: easy

---

According to: https://wiki.debian.org/XDGBaseDirectorySpecification It is not a required change but "strongly encourages upstreams" to use the XDG folders.

The original sec is found here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

The following locations are defined, but the environment variables are not set in any distro (like Ubuntu)

$XDG_DATA_HOME (default: "~/.local/share"): user-specific data files.
$XDG_CONFIG_HOME (default: "~/.config"): user-specific configuration files.
$XDG_CACHE_HOME (default:  "/.cache"): user-specific non-essential data files.

[mixxxbot]

Commented by: daschuer Date: 2015-06-09T06:37:26Z

---

Related: https://bugs.launchpad.net/mixxx/+bug/302811

[mixxxbot]

Commented by: kain88-de Date: 2015-06-09T08:53:38Z

---

This will make it hard for users to change between mixxx installations (so far it is really easy to switch between any version from 1.8 - 1.12 back and forth). Also at least for cross-platform programs there seems to be an issue conforming to the XDG-standard. IPython tried to use the XDG paths in one of the 2.x versions but soon switched back because it caused more problems for users then solved things. (I can't find the commit explaining the change right now). From what I remember it was mainly a problem with the way OSX handles things.

[mixxxbot]

Commented by: daschuer Date: 2015-06-09T09:11:50Z

---

https://github.com/mixxxdj/mixxx/pull/606 will break the 1.8 - 1.12 path compatibility for windows. We may consider if it is worth to do this change as well for Linux.

Maybe we find a way to retrain the compatibility. Something like this: Detect if a ~/.mixxx folder exists. if yes, move its content to ~/.local/share/mixxx and replace it by a symlink.

[mixxxbot]

Commented by: sblaisot Date: 2015-06-09T09:28:06Z

---

I don't think that XDG folders are already "natural" for users at the moment.

This change should be postponed post 1.12 IMHO. It needs mote testing and a clear communication.

[mixxxbot]

Commented by: daschuer Date: 2015-06-10T07:27:24Z

---

It looks like the standard paths on Linux are broken in QT 4. They where revamped in QT5 http://doc.qt.io/qt-5/qstandardpaths.html

Debian recommends using libqtxdg

Unfortunately it is not part of Ubuntu Precise. Version 0.5 It is part of Ubuntu Trusty

The library supports Qt4 up to version 1.2
The it switches to the underlying Qt5 implementation form version 1.2 https://github.com/libqtxdg/libqtxdg/tree/da936792f2376327db2c287348738ede394e7bcc

I think the following approach is reasonable: Use QString XdgDirs::dataHome(bool createDir) from Trusty. Hardcode "~/.local/share/Mixxx" for Precise The xdg environment variables are not set anyway.

[mixxxbot]

Commented by: daschuer Date: 2015-06-10T07:32:15Z

---

Is this a 1.12 bug? I think yes, since we fix the issues on the other OSs as well. We can deal with the time up to 1.11 and from 1.12 unique over all Os

The approach from https://github.com/mixxxdj/mixxx/pull/606 will work here as well:

• new preference folder are created in the right place
• former preference folder used if they are found, and no new folder is created
• if both former path and new path exist, the new path is prefered

[mixxxbot]

Commented by: daschuer Date: 2015-06-13T20:19:03Z

---

Since libqtxdg is only a thin wrapper in Qt5 and can't control if the distros version is compiled with Qt4 or Qt5 or if it is available at all. I think it is best to just copy the needed view lines from libqtxdg and qt5 into the Mixxx soure.

[mixxxbot]

Commented by: daschuer Date: 2015-06-14T12:35:28Z

---

Here are some guidelines how to use the .dot folders https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders

[mixxxbot]

Commented by: sblaisot Date: 2015-06-14T13:02:40Z

---

Because we're talking about standards :

Filesystem Hierarchy standard: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html If an application needs to create more than one dot file then they should be placed in a subdirectory [of home dir] with a name starting with a '.' character, (a "dot directory"). In this case the configuration files should not start with the '.' character.

Linux Standard Base: http://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html An LSB conforming application shall conform to the Filesystem Hierarchy Standard.

We're actually compliant with LSB 5.0 and FHS 3.0

Complying to XDG base directory spec will need to split preference folder into more folders (config, data & cache). I think this is not a 1.12 target.

I propose to keep as it is for 1.12 and try to work on it on all systems for next version.

[mixxxbot]

Commented by: daschuer Date: 2015-06-14T19:04:34Z

---

Thank you for the link. Now its clear for me. It includes a clear reference to the XDG and Glib which also use the XDG dirs. Using the .config /.cache /.local folders is compliant to §3.8.2, but we are not forced to give up .mixxx

Also interesting: we must not assume that .config /.cache /.local are available.

[mixxxbot]

Commented by: illuusio Date: 2015-06-15T12:34:55Z

---

My opinion is also that we should postpone this feature after 1.12. Big feature which needs time to settle and migration plan for users. XDG is highly optional but makes home dirs more clear like in Mac OS X. Symlink to .config/mixxx from .mixxx would make nostalgic happy for 1.13?

[mixxxbot]

Commented by: daschuer Date: 2015-06-15T13:30:31Z

---

I have already removed the 1.12 target.

Please note: we are talking about two different things:

1. move ~/.mixxx to entirely to ~/.lacal/share/Mixxx The equivalent is already done for Mac. A solution is in https://github.com/mixxxdj/mixxx/pull/622

2. Split the .mixxx up to data / config / cache as decribed here: https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders These three folders are supported on Mac an Linux but not on Windows.

If we plan 2. soon 1. does not make sense yet. If we are satisfied with 1. we can do it when ever we like.

[mixxxbot]

Commented by: sblaisot Date: 2015-06-15T14:00:19Z

---

Under windows, such a split also makes sense by using AppData\Local for cache and AppData\Roaming for config+data

I think it's the way this is implemented in QT5.

sb

[mixxxbot]

Commented by: daschuer Date: 2015-06-15T14:26:05Z

---

Look at: qstandardpaths_win.h

All three folders are pointing to  
CSIDL_LOCAL_APPDATA
Which is 
C:\Benutzer\Benutzername\AppData\Lokal 
on win7
subfolder cache is added for cache. 

[mixxxbot]

Commented by: sblaisot Date: 2015-06-15T18:55:27Z

---

This is how it is implemented, not how it should be ;)

Under windows, the standard is to have under roaming everything that should be shared between computers on which the user can connect to (shared like sync, not like NFS share), and under local everything that can be removed / not synced without impact on software configuration and behaviour. I agree that reality is often far from theory on that point.

QStandardPaths::DataLocation is deprecated in QT5 and it is stated : //This enumeration value is deprecated. Using AppDataLocation is preferable since on Windows, the roaming path is recommended.//

Preferred way is to use QStandardPaths::AppDataLocation which ends in roaming path and QStandardPaths::AppLocalDataLocation for local files (cache for example)

I think that QT is missing something by putting ConfigLocation in the Local folder. If user changes computer in the same "network", it looses all his preferences (which in case of mixxx is not really a problem because Mixxx also needs to be install, to access library, and most of all is not designed to be installed in a large network of computers sharing data and config). This can be more of a problem for, say, a QT software used by several people in an enterprise network that often change computer on which they connect to.

[mixxxbot]

Commented by: sblaisot Date: 2015-06-15T18:56:11Z

---

Oh, you're right, my thought about QT implementation were wrong :(

[mixxxbot]

Commented by: rryan Date: 2018-09-20T17:52:51Z

---

Due to lack of progress, marking Triaged and clearing assignee. Feel free to revert if it is in fact still in progress :).

[mixxxbot]

Commented by: Be-ing Date: 2021-01-12T02:42:02Z

---

I think we should finally do this for 2.4.

[mixxxbot]

Commented by: ywwg Date: 2021-01-12T16:16:42Z

---

yes please!

[mixxxbot]

Commented by: bart-ribbers Date: 2021-10-29T08:48:21Z

---

Every once and while I experiment with setting my $HOME to read-only and see what breaks, Mixxx is one of those. My home folder is full of config folders and data, and it makes it hard to backup say only the config files for use on another machine. I would love 2.4 to have full XDG support, it's nice to keep to existing standards rather than making your own.

[mixxxbot]

Commented by: Holzhaus Date: 2021-10-29T14:14:27Z

---

I had some initial work in the pipeline, but stopped eventually due to all the other tasks. As a first step, we should introduce a class that allows accessing the different path types (cache, data, config) and use it everywhere. Then we can add support for XDG basedir spec to that class, so that we don't need OS specific ifdefs everywhere.

[mixxxbot]

Commented by: Be-ing Date: 2021-10-30T08:01:26Z

---

I like that plan, Jan. A lazy hack of kludging everything we currently put in ~/.mixxx into a single XDG directory wouldn't be a great user experience.

[mixxxbot]

Commented by: Be-ing Date: 2021-10-30T18:10:00Z

---

I think this would be a good feature to implement for a new contributor following the plan Jan described above. It would not be trivially easy but I don't think it would be very hard and would be a good introduction to the Mixxx code.

[mxmilkiib]

Why not just allow the config at both? Check one, then check the other. That's what, AFAIU, many apps do these days.

[audio2000]

I did not realize my recent post was a duplicate 13618, I closed it. Yeah that would be great if that can be done, just checking both locations. If not then maybe can just add some kind of option with field that allows user to choose a path linked to this folder. Again better if this could just be done as user mentioned above.

[Krafting]

Would be cool if Mixxx followed XDG specs indeed ! :)

[acolombier]

Is that something you would like to help implement? Do feel free to submit PR, even if it isn't complete, I'll be happy to help you finish it if needed! :)

[Krafting]

Is that something you would like to help implement? Do feel free to submit PR, even if it isn't complete, I'll be happy to help you finish it if needed! :)

I've looked at the code, and it doesn't seems that hard to fix, the hardest step would be implementing an upgrade path, to take the old folder and move its content to the new one.

I might take a shot at it next week when life get less busy!

[daschuer]

take the old folder and move its content to the new one

This would make beta testing hard. After testing a beta, the stable version will no longer find .mixxx and create a new one: everything gone ... How can we improve the situation? Maybe don't copy, use the old folder if found, but default to the new if not?

[acolombier]

I think it would be great to support both locations for now, and create in the new XDG compatible location on new setup only, yes. This way we don't have to worry about migration/backwards compatible problems.

It may be great to also put the old config path behind a build flag, so we can easily turn it off in the future (eg: for version 3.0.0)

[Krafting]

I think it would be great to support both locations for now, and create in the new XDG compatible location on new setup only, yes. This way we don't have to worry about migration/backwards compatible problems.

It may be great to also put the old config path behind a build flag, so we can easily turn it off in the future (eg: for version 3.0.0)

seems like a better idea than copying data indeed!

[ronso0]

My 2 ct: what I appreciate about the current 'one config directory' implementation is that easy switching between profiles via --settingsPath and easy backup of config, db, mappings and analysis with one move.