stellarium Switch to XDG base directory specification on Linux / Unix

Switch to XDG base directory specification on Linux / Unix

Open shmerl opened this issue 6 years ago • 24 comments

Currently Stellarium is using $HOME/.stellarium for storing configuration and other data.

It's proper to switch to XDG base directory spec instead.

Jan 14 '18 18:01 shmerl

Why is it "proper"? What may be the advantages? How would it look like? Are the XDG_... variables pre-defined on major distributions? (Don't see it on Debian)

You can set XDG_... to ~/.stellarium (or include it there, if you need this path for other programs), or run Stellarium with the --user-dir switch to use some other directory.

Jan 14 '18 19:01 gzotti

Because it's a standard on Linux, and other Unixes these days.

The main benefit is decluttering $HOME. It's up to applications to support it, not up to distributions. Search around for switching to XDG base directory spec. Basically everyone has been switching to it for a while.

The point is not to set anything, but for it to use correct locations (see the spec).

I.e. if $XDG_CONFIG_HOME / $XDG_DATA_HOME are not set, then use $HOME/.config and $HOME/.local/share, and if they are set, use them accordingly.

Which would result in:

$HOME/.config/stellarium
$HOME/.local/share/stellarium

When they aren't set, and in:

$XDG_CONFIG_HOME/stellarium
$XDG_DATA_HOME/stellarium

When they are set. Whether to use both, or just let's say data dir is up to you. Some applications split to both, some not. But the main benefit of decluttering $HOME is still there.

I can make a pull request for this if needed.

Jan 14 '18 22:01 shmerl

OK, thanks for the explanation, I was not aware of this. Seems reasonable then. A PR would likely speed up things :-) , but please wait for comment by @alex-w .

Jan 14 '18 22:01 gzotti

First sentence - not all linux distros and not all Unixes support XDG!

@shmerl are you really want to see support of these "specification"? Please do it you yourself. Without loss of functionality (hello network instances in universities and schools for example), with support systems, who known nothing about XDG (hello classic UNIX'es, Windows and Mac OS X), with wrapper for logging loading and work process on different loggers and systems (Stellarium's log should be available to read not only by unix-guru of course). When you do all those stuff please propose pull request.

And tool for migration all data from old standard place to XDG should be proposed also.

In addition, all directories (place and purpose) should be well documented for users.

Jan 15 '18 02:01 alex-w

not all linux distros and not all Unixes support XDG

Do you have any example?

XDG (hello classic UNIX'es, Windows and Mac OS X)

Do you refer to FreeBSD? They have nothing against XDG base directory spec. Same as let's say illumos based systems. I don't count macOS among them, so let's leave that aside, same as Windows. They aren't using $HOME/.stellarium either, right? We are only talking about these.

As for migration tool - that can be useful to make the switch easier, but not necessary for new installations. A simple way to do it is for example to show a warning message on startup (for certain range of versions). Most users will figure out transition pretty easily, so it's not a major problem vs actually removing the clutter.

You can also simply check for existence of $HOME/.stellarium, and move the data to new location as a migration step.

Jan 15 '18 03:01 shmerl

I don't count macOS among them, so let's leave that aside, same as Windows. They aren't using $HOME/.stellarium either, right? We are only talking about these.

Stellarium on Mac OS X and Windows using the same directory hierarchy, but with other value for StelFileMgr::userDir variable. You propose remove this variable and introduce few other for the different places - it's OK, but you should update all stuff for Windows and Mac OS X also! If you want just add XDG for linux only and broke directory hierarchy for all other OS - it's very bad proposal and it never will accept.

Most users will figure out transition pretty easily, so it's not a major problem vs actually removing the clutter.

In my opinion resolving the clutter by introducing more cluttering is very strange solution.

You can also simply check for existence of $HOME/.stellarium, and move the data to new location as a migration step.

Sorry, but this is your proposal and your problem to resolve users troubles.

Jan 15 '18 03:01 alex-w

You propose remove this variable and introduce few other for the different places

Not necessarily. As I said above, if you prefer to use one location, you can just use the data one, which will work same way with current StelFileMgr::userDir, just will provide a different value instead of $HOME/.stellarium. But if you want to split it into two let's say, then sure, there will be two variables like StelFileMgr::configDir and StelFileMgr::dataDir, and in case of Windows or macOS they can just point to the same place as now StelFileMgr::userDir does. That's something you should probably decide what you prefer more (i.e. use one or split in two). I don't really have a preference.

Jan 15 '18 03:01 shmerl

@shmerl apparently you never read the XDG specification :D

Jan 15 '18 03:01 alex-w

Sure, I've read it. But same way, I don't see a need to implement all features of it, as long as its goal is achieved - decluttering. But if you want to also gain separation of config and data - sure, why not. As I said above, it wouldn't really disrupt what other systems are doing which don't use such separation.

I have a pragmatic interest here - remove .<xyz> clutter from $HOME.

Jan 15 '18 03:01 shmerl

Seriously? Enable XDG support is your proposal. And just movement the directory from place A to place B is not implementation of specification. If you do not understand it, then this is very bad. You are proposed PR also, so, in this case you should implement XDG support for main application and all plugins. Not just movement of the directory! And you should implement support of logger, who is not described in XDG of course too.

If your PR will be just changing line userDir = QDir::homePath() + "/.stellarium"; to userDir = QDir::homePath() + "/.local/share/stellarium"; then... sorry, but this is not a solution.

Jan 15 '18 04:01 alex-w

I explained the goal of it - to declutter home. I see no point in theoretical bikeshedding of the split issue, I asked explicitly what you prefer. So if you want the split - the split it is.

And I'm not sure what problem do you see with the logger. Currently it logs to the user dir, so it will log to data dir. Is that a problem?

Jan 15 '18 04:01 shmerl

OMG, you are definitely did not read the specification. :(

Jan 15 '18 05:01 alex-w

Let's get back on topic please. You said you see a problem with the log there. What is it exactly?

Jan 15 '18 05:01 shmerl

Could you implement XDG BD spec through Qt's standartdirectories?

Jan 16 '18 03:01 alex-w

I'm not familiar with that, but if they correctly map to XDG base directories, then why not. It would save the logic of calculating them manually through reading getenv and etc.

For instance in http://doc.qt.io/qt-5/qstandardpaths.html these look useful:

QStandardPaths::ConfigLocation
QStandardPaths::AppConfigLocation
QStandardPaths::DataLocation
QStandardPaths::AppDataLocation

I suppose they read XDG_* env variables correctly if they are set, and fall back to defaults otherwise, but it's not clear from the page above.

Jan 16 '18 04:01 shmerl

Probably using the QStandardPaths would be the most useful solution if we change the current way of finding files. After all, Stellarium is clearly based on Qt, but not on XDG.

I would prefer to keep all things in one directory, so for most Linux installations this would just move ~/.stellarium to ~/.local/share/stellarium. If somebody has configured XDG_... variables, these would however have to be observed, or at least the directories listed in the Qt docs must be handled correctly. Should we then assume "all files in one location listed there", or "all files anywhere in the list of directories"? Is it a conceptual problem for XDG brains if config.ini and logfiles are in there as well?

On Windows, using QStandardPaths::AppLocalDataLocation would be the obvious choice: current location will be used, but the system would then also be able to find (read-only) data in C:\ProgramData\Stellarium, C:\Program Files\Stellarium, C:\Program Files\Stellarium\data or even C:\Program Files\Stellarium\data\Stellarium. It would finally allow shared installations of landscapes, skycultures etc on multi-user systems without touching the program folder. (Currently these are personal files in AppData\Roaming).

Jan 16 '18 10:01 gzotti

@gzotti :

Should we then assume "all files in one location listed there", or "all files anywhere in the list of directories"?

In practice, I saw different applications following XDG spec strictly, splitting the data and configs into two locations (and some even cache to third), while some don't follow it too strictly and simply use data one for everything.

How to proceed is really up to you as owners of stellarium to decide. Apparently @alex-w prefers stricter separation. On the other hand, on Windows you already are using only one location, so unless you want to split it there as well, there may be a benefit of keeping the logic consistent across systems, while still achieving decluttering of $HOME.

Approach in between can also work, if for example for Windows both locations will just point to the same place.

Jan 16 '18 13:01 shmerl

Repeat from duplicate #461:

Original report by Eric Heintzmann: https://bugs.launchpad.net/stellarium/+bug/1088064

Please support FreeDesktop.org XDG basedir specification for stellarium

http://ploum.net/post/207-modify-your-application-to-use-xdg-folders https://live.gnome.org/GnomeGoals/XDGConfigFolders http://standards.freedesktop.org/basedir-spec/latest/

Sep 26 '18 09:09 gzotti

Why not simply use QStandardPaths::AppConfigLocation and be done with it? QStandardPaths seems to be compliant to the XDG spec.

Sep 22 '19 18:09 10110111

@rharriso

I see in StelFileMgr::migrateLegacyUserDirectory() that a move is performed.

https://github.com/rharriso/stellarium/blob/6ee039e644616347d42f192746bb491c35332d93/src/core/StelFileMgr.cpp#L287-L295

Even if this is currently commented out, and even if the user has to acknowledge with a yes/no, you have to keep in mind that users still risk to click the wrong choice, or click too fast and not realise what happens, etc. Normally, nothing bad should happen, but can you guarantee that? What if the app crashes during the move? What if there is a power loss during that very moment?

Better is to copy everything. The app should rename the original directories with a date-time prefix (and maybe an extra indication, such as stellarium-config-old-yyyy-mm-dd-hhmmss) to make absolutely sure that the migration will never delete anything by mistake, by a bug, etc.

Just issue a notification, and let the user decide on finally deleting the old directory; this is trivial. In the worst case, the user ends up with some clutter. In another worst case, the user can revert the changes (even if the app might try to perform them again in a next invocation); the user will always have the option to use an older version of the app if really needed.

But in yet another worst case, if something goes wrong, the user might weep a lot. Especially when this can be prevented.

stellarium stellarium copied to clipboard

Switch to XDG base directory specification on Linux / Unix

stellarium
stellarium copied to clipboard