Hydrogen: ~/.hydrogen does not follow XDG standards

[ghost]

Hydrogen makes a .hydrogen directory.

.hydrogen
├── data
└── hydrogen.conf

1 directory, 1 file

XDG standards specify that config files should go in ~/.config and data in ~/.local/share.

Therefor, the ~/.hydrogen/data directory should be moved to ~/.local/share/hydrogen and hydrogen.conf should be moved to ~/.config/hydrogen.conf by default.

[elpescado]

That's because Hydrogen predates XDG spec, and .hydrogen dir has been kept for backwards compatibility.

[ghost]

Then how about using symlinks?

[mauser]

Hi!

Moving the config file to a different problem shouldn't be such a large problem, we could save the file in
~/.config/hydrogen.conf and favour this location over .hydrogen when loading the config file.

The data could be a larger problem since due to all of those references in song files, but a symlink for backward compatibility could work.

[jeremyz]

Hi,
It's on my TODO list, I did send a mail about that very same point to the ML on Tue, 17 Apr 2018.
About the data, maybe, on h2 startup if there is a .hydrogen/data directory,
we ask the user if we can move that directory to ~/.local/share/hydrogen, otherwise h2 exit.

[trebmuh]

About the data, maybe, on h2 startup if there is a .hydrogen/data directory, we ask the user if we can move that directory to ~/.local/share/hydrogen, otherwise h2 exit.

@jeremyz I do understand that we want to _transition_ (and encourage users to transition) from ~/.hydrogen/data to ~/.local/share/hydrogen/data, but don't understand why H2 should exit if not?

[elpescado]

I like this idea, but have some questions/remarks.

1. Should we ask user to upgrade or just upgrade silently?

2. Leave old .hydrogen directory during migration or leave it so users can revert to older version without losing config?

3. What happens if user has both .hydrogen and XDG configs? Load only XDG? Load both and prefer XDG? What if .hydrogen/data contains drumkits A and B and .local/data/hydrogen has drumkits B and C - what drumkits should be available to user - B,C (XDG only)? A,B,B,C (union)? A,B,C (unique union)?

hydrogen.conf should be moved to ~/.config/hydrogen.conf by default.

To be precise, it should be moved to ($XDG_CONFIG_HOME or $HOME/.config)/hydrogen.conf

Therefore I fear this not as simple as it seems at first sight and on the other hand benefits are not that big.

[riri]

One solution would be to degrade gracefully for each of the two points (configuration and data) :

• First check command line arguments
• If not specified, check and load from what should be nowadays (XDG compliant)
• If not exists, check and load from old location
• If not exists, create at new location (XDG compliant)

For configuration:

1. -c path-to-config-file (new one to define) set? use it
2. $XDG_CONFIG_HOME/hydrogen.conf exists? load from it
3. $HOME/.hydrogen/hydrogen.conf exists? load from it
4. nothing exists, create $XDG_CONFIG_HOME/hydrogen.conf

For data:

1. -P path-to-data-dir set? use it
2. $XDG_DATA_HOME/hydrogen exists? use this as base directory for data
3. $HOME/.hydrogen/data exists? use this as base directory for data
4. nothing exists, create $XDG_DATA_HOME/hydrogen

That would need a bit of work in Filesystem helper. I don't think other source files should be impacted, except the defaults in project configuration, but I gave just a brief look at the source code, and I don't really know much about Qt and Cmake :)

I don't think an automatic move should be used. At most, a question could be asked to the user on startup if the configuration or the data are the old locations, if they want to migrate to new location.

Or that could be a specific task available in the preferences (people keep the choice to stay with the old location or migrate)

[jeremyz]

I've just started working on it https://github.com/hydrogen-music/hydrogen/commits/xdg

[jeremyz]

Hi @mauser, @trebmuh, @elpescado, @riri, and others

can you check xdg branch please.

on a unix box, you can try it like that :
XDG_CONFIG_HOME=$HOME/fake_cfg XDG_DATA_HOME=$HOME/fake_data ./build.sh z
you should end up with $HOME/.hydrogen/hydrogen.conf copied to $HOME/fake_cfg/hydrogen.conf
and data copied from $HOME/.hydrogen/data/ to $HOME/fake_data/hydrogen.
songs and playlists filename attributes should be fixed ... is there other xml attribute to fix ?

[riri]

I have never built hydrogen, and it seems I am missing some parts on ArchLinux (although dev packages are always included). I get: no rule to make the target "translations". Don't worry about that, I will check how hydrogen is packaged.

Isn't there the autosave file in user's directory? (I can't find one in my current installation, but I remember seeing it) This one should be in $XDG_DATA_HOME/hydrogen

[jeremyz]

Hi, you need qt5-tools, songs autosave files are in $XDG_DATA_HOME/hydrogen/songs

[riri]

I could build using my own build script, and it works. All data are transferred in the locations defined by XDG variables :

• $HOME/.config/hydrogen.conf
• $HOME/.local/share/hydrogen : content of old $HOME/.hydrogen/data

but data is copied.... isn't it too much if the user has a huge set of data ? Shouldn't it be moved instead?

[jeremyz]

is the data OK, or have you paths in some xml files that still reference the old path ?
grep -R 'hydrogen/data' ~/.local/share/hydrogen/

moving data would be much more easier, but I fear having user reports saying 'launched H2 0.9.X I've lost all my data'.
I've hadded 2 bool in Filesystem.h config_migrated and data_migrated, so we can add a msgbox that says, data has been copied from X to Y, do you want us to delete X ?

if we move data and set symlinks old_data -> new_data, running 0.9.x should work, but songs generated from it would have layer filename that wont work when going back to 1.x.y ...

[riri]

is the data OK, or have you paths in some xml files that still reference the old path ?
grep -R 'hydrogen/data' ~/.local/share/hydrogen/

All seems ok, no reference to the old path :)

moving data would be much more easier, but I fear having user reports saying 'launched H2 0.9.X I've lost all my data'.
I've hadded 2 bool in Filesystem.h config_migrated and data_migrated, so we can add a msgbox that says, data has been copied from X to Y, do you want us to delete X ?

To me the message method is good, the user then knows about paths that changed. If they dont bother with geek things, they will choose whatever is the default. Those aware and sensitive to this will make their choice : move (delete old) or copy (do not delete old).

if we move data and set symlinks old_data -> new_data, running 0.9.x should work, but songs generated from it would have layer filename that wont work when going back to 1.x.y ...

For this, once users update to 1.x.y (and then has there data migrated), they wouldn't generate new songs with 0.9.x, except hydrogen developers and testers. I don't think that's so important (but I see only my usage).

Edit: I have just checked one song xml content, and in each instrument nodes, there are only the name of the drumkit and and filename (without path) for layers.

[jeremyz]

Edit: I have just checked one song xml content, and in each instrument nodes, there are only the name of the drumkit and and filename (without path) for layers.

I see now that full path is used in autosave files, should not be, will fix that ...

[elpescado]

The only thing that I'm afraid of is that copying user data, especially drumkits, might result in shuffling large amount of data around. That in turn might take time, freezing GUI and delaying startup in meanwhile. I'm not sure if that's real problem today, in the age of crazy fast SSDs, though. If so, maybe we should show dialog box (possibly with progress bar?) explaining what's going on?

Plus, what happened when those two copies go out of sync?

Alternatively, we already load drumkits from two locations: one system (/usr/local/share) and one user (~/.whatever/data). Maybe we could just add third location, XDG-compliant one, and prefer that when writing. Any thoughts?