Move ~/.lmmsrc.xml to canonical config location

[sqrvrt]

Moves $HOME/.lmmsrc.xml to $XDG_CONFIG_HOME/lmms/lmmsrc.xml (and similar dirs in other platforms) to conform to modern standards.

Currently in this PR, if file doesn't exist in new location, old one gets copied, and if directory doesn't exist it gets created on startup instead of on write like the file does. Should i move it? Creation also silently fails if directory is somehow unable to be created, though i'm not crazy enough to test if writing a file would still emit a warning.

Worthy of note, since it's now a proper config file, the leading dot is removed. Instead of copying old file could be moved. Current behavior is for testing convenience.

[Monospace-V]

I would copy and not move because in my case (and I think at least some other users do this too) I'm running multiple versions of LMMS. I think this could be more likely in the future if there are changes that break backward compatibility. I know a lot of other users who switch from nightly back to alpha, etc, or try out nightly and go back to stable.

[sqrvrt]

My main argument for moving was just somewhat of a clarification that file being observed has moved, but i see the problem. Would probably be good to get the point across in some way though without reading the patch notes, maybe a popup after file copying?

[sqrvrt]

Popup is probably unnecessary. Peki asked me to abstain from touching this for a while, but i'd remove it before merging.

[rubiefawn]

Does this supersede #6005?

[sqrvrt]

Had no idea that existed, although it seems to achieve roughly the same thing. Why wasn't it merged?

The only factual difference which i believe to have done better is using ${QStandardPaths::GenericConfigLocation}/lmms instead of QStandardPaths::ApplicationConfigLocation because the latter depends on Qt's internal knowledge of QApplication::ApplicationName, which in master is unset, which makes it use the executable name, which due to some changes is now AppRun.wrapped on linux builds, so a ~/.config/AppRun.wrapped/lmms.xml would be created in the linked PR. Regardless, it would be an easy fix for that one too.

Can't really explain the difference in LoC, but at a glance they seem to have rewritten some of the directory initialization code for reorganization purposes, which is moderately tangential to the PR itself. The only edge case in mine is that when a -c /path/to/custom/lmmsrc.xml is provided, an empty ~/.config/lmms/ is still attempted to be created, but i don't see a reason for why that would be particularly bad.

[tresf]

I believe AppDataLocation should be used. Qt defined GenericConfigLocation as a place for shared data and I've never seen a use-case where lmmsrc.xml should be shared.

To this point, I think there are some other advantages to the approach used in #6005, notably the name lmmsrc.xml ➡️ lmms.xml. I'd even go as far as to ask for a non-xml format, although that might be better tackled in a separate PR.

I would copy and not move because in my case (and I think at least some other users do this too) I'm running multiple versions of LMMS. I think this could be more likely in the future if there are changes that break backward compatibility. I know a lot of other users who switch from nightly back to alpha, etc, or try out nightly and go back to stable.

Assuming we keep the same format, we could create a symbolic link to the old location with a clear @deprecated tag in the function declaration... or just hard-code a version cutoff (e.g. 1.5.0) where we just stop making the symlink.

I'm also fine with the file move, since we've never officially supported downgrades, but I think @Monospace-V's request has merit considering how infrequently we release stable versions.

[sqrvrt]

I believe AppDataLocation should be used. Qt defined GenericConfigLocation as a place for shared data

I think you misunderstand what Qt is trying to say. Qt's ApplicationConfigLocation is defined strictly as GenericConfigLocation/appname. The idea behind the generic one is that one would only want to use it instead of the app-specific one in an app if they want to avoid using the application dir. Because of what i outlined above, i believe that specifying app dir manually makes it more predictable.

As far as config/data goes i believe lmmsrc is still mostly config-shaped, even though some of the stuff in it is more of a data/cache. *DataLocation is the one that would use ~/.local/share/

[tresf]

i believe that specifying app dir manually makes it more predictable.

Yeah, I forgot about the appimage naming bug, but that's orthogonal to the point, it's still the wrong place. I'm sure you could make the argument that lmmsrc.xml is a config file so belongs in what Qt called "configuration", however on macOS, the configurations home is GenericConfigLocation --> ~/Library/Preferences, which is reserved for macOS-only formatted plist files in the format of io.lmms.lmms.plist.

I think you'll also find that Linux GenericConfigLocation --> $XDG_CONFIG_HOME is generally reserved for plain text config files, so by leveraging these GenericConfigLocation we'd be suggesting that we'd use a platform-specific storage location.

To the best of my knowledge on Windows these point to the same location.

[sqrvrt]

To the best of my knowledge on Windows these point to the same location

They do not, configs are in AppData/Local and data is in AppData/Roaming. As for MacOS thing, Qt docs define AppConfigLocation as ~/Library/Preferences/<APPNAME> so i would assume that if Qt endorses that it's probably fine.

I think you'll also find that Linux GenericConfigLocation --> $XDG_CONFIG_HOME is generally reserved for plain text config files

Yes, and .xml is plain text.

to clarify, the structure is kept as ${GenericConfigLocation}/lmms/lmmsrc.xml, so it still is in a subdirectory.

[tresf]

so i would assume that if Qt endorses that it's probably fine.

This is a false assumption. Please see similar mistake made here: Canop/broot#103

They do not, configs are in AppData/Local and data is in AppData/Roaming.

You're right, I was accidentally looking at GenericDataLocation. Regardless, AppDataLocation is the most correct location, so correcting this mistake doesn't negate this. AppData/Roaming is just fine. ~/Library/Preferences/ is not fine and I'll reitterate that ~/Library/Preferences/APPNAME is not fine either unless Qt's smart enough to place the io.lmms.lmms portion, but even then, we must convert our XML to a proprietary plist file. This isn't a bad idea, but changes the scope of this PR.

Yes, and .xml is plain text.

So is base64. I won't die on that hill, if you believe that Linux belongs there, I won't fight it, but Mac doesn't. I compared ~/.local and ~/.config locally and can't really find any rhyme or reason. For example, Gnome Text editor stores its recently opened files in ~/.local which is more of a configuration file we also store in our configuration file (also formatted XML, coincidently), whereas JDK mission control stores it's SQLite database there, which makes sense. ~/.config seems to be mostly ini-style config files, which we don't yet use, but this doesn't seem to be strictly followed. Note that the user's autostart folder is also in ~/.config, for whatever that's worth. Many many apps still use the older ~/.<appname> though, so this may be a classic case of app developers suffering from decision paralysis.

With regards to Windows, %APPDATA% (e.g. Roaming) is much easier to support in the field and should be preferred, so if we leverage GenericConfigLocation, it should be the exception, not the rule.

[tresf]

As far as config/data goes i believe lmmsrc is still mostly config-shaped, even though some of the stuff in it is more of a data/cache.

I would agree with this and I'm sorry if my previous reply missed this point, but I still feel that this value is functionally Linux-only. On Windows, AppData/Roaming files are intended to move from machine to machine wherase AppData/Local are not. I'm uncertain why Qt chose AppConfigLocation to point to Local and AppDataLocation to point to Roaming, but roaming seems more suitable for the config portions, not for the data/cache portions. This a bit contradictory of a Qt choice, but regardless, I find %appdata%/<appname> and ~/Library/Application\ Support/<appname> to be overwhelmingly more common in the field.