Create dsda-doom directory in $XDG_DATA_HOME or .local/share by default

[spazzylemons]

This is the same PR as #461, but moved out of my main branch. The initial intent was to make it easier to create a Flatpak package, but this change probably should be done regardless as it's better practice to store application-specific data in a subdirectory in $XDG_DATA_HOME than storing it as a subdirectory in the home folder.

With these changes, the directory used to store DSDA-Doom's data will be $XDG_DATA_HOME/dsda-doom (or $HOME/.local/share/dsda-doom if $XDG_DATA_HOME is not set). However, to avoid breaking the application for existing users, $HOME/.dsda-doom is used if it exists.

[Pedro-Beirao]

Imo, ~/.dsda-doom should be the preferred directory, like it has historically been done in doom source ports Whether this is good practice or not, is debatable.

Also, the PR does not take macOS into account. XDG_DATA_HOME is not a thing on macs

About the approach itself, migrating data to the new directory would be better than using the old directory if available

[spazzylemons]

migrating data to the new directory would be better than using the old directory if available

My only concern about this would be that users used to the old directory would likely be confused as to where their data has gone. Perhaps the data could be moved to the new directory while creating a symlink in the old directory's place?

the PR does not take macOS into account

How would this be implemented on macOS? I don't have a Mac myself. Is ~/Library/ the equivalent?

[Pedro-Beirao]

Perhaps the data could be moved to the new directory while creating a symlink in the old directory's place?

That would be better.

How would this be implemented on macOS? I don't have a Mac myself. Is ~/Library/ the equivalent?

~/Library/Application Support/ is the equivelent. But it is not usually a folder meant for users to access.

[mooreye]

Personally, I have never encountered a program that makes a symlink to old config directory, they just continue using legacy dir if not empty. However, creating a symlink doesn't sound too bad.

Migration I would be against personally, because there are many things that can go wrong - absolute symlinks pointing to wrong files, file movement failing for some reason mid-way (like permissions), it could be interrupted, etc.

[spazzylemons]

Maybe the best approach would just be a warning popup, and an option to relocate the directory automatically (without the symlink)? Something like:

"Your data is currently stored in $HOME/.dsda-doom. However, going forward, DSDA-Doom will store its data in $XDG_DATA_HOME/dsda-doom. Would you like to migrate the directory automatically? Note that symlinks will not be moved, so for example if you store your WADs in DSDA-Doom's data directory and symlink to them for another source port, these symlinks will break. [Yes/No]"

[mooreye]

I don't know C well but the main question is probably if someone can even write such a migration utility in reasonable timeframe?

Also, only absolute symlinks that point to the same dir will break, not relative ones. And if someone for some reason links anything from DSDAdoom's dir to somewhere else on the system, it will break regardless. This plus the potential migration problems is why just a symlink to new dir would be better IMHO

[drelbszoomer]

User here, if it helps - I don't think migration is really needed, from my perspective.

XDG_XXX paths are a pretty well-established standard for all desktop envs, and all major Linux desktop envs encourage the use of XDG_XXX standard paths.

I'd suggest simply creating + preferring the standardized XDG path if ~/.dsda-doom doesn't exist. For flatpak, the XDG path will then always be used (since it doesn't assume or by-default allow unsandboxed /home access), and for all other non-flatpak new users the XDG path will also always be used.

Existing users with existing ~/.dsda-doom paths will continue to use that (unless they delete/move manually - most people will never bother, but a sentence or two in the README can explain how for the motivated)

[drelbszoomer]

And as mentioned here: https://github.com/kraflab/dsda-doom/issues/283

Prboom+ already implemented XDG_DATA_HOME wad loading the way @spazzylemons has done in this PR - that should be sufficient.

[kraflab]

Odd that github reports no conflicts when this PR is editing a function that was split apart and the edits are on the wrong function now 🤔 Gonna adopt this to the current master.

[kraflab]

Done here: https://github.com/kraflab/dsda-doom/commit/38fc904d32f434a8ead3d8c815753fa13e9cdb70

Thanks!