Bug #1725703 “Follow XDG basedir specification” : Bugs : widelands

Revision history for this message

SirVer (sirver) wrote on 2017-10-21:

#1

I am against this. Here are my 2c: First XDG is an opinion - I for one much prefer pure dotfile directories instead of smearing everything across an entire tree. Second, Widelands has done dotfiles for > 15 years, like vim and emacs - it works well and is well tested. Third, the pain of implementing this and transitioning old directories over is substantial and the gains are minimal.

+1 for wontfix.

Revision history for this message

SirVer (sirver) wrote on 2017-10-21:

#2

I forgot some stuff: XDG does not transition well to Mac OS or Windows, needs documenting since it is much more complex and can easily be expressed using symlinks.

Revision history for this message

kaputtnik (franku) wrote on 2017-10-21:

#3

I don't like the splitting of an applications data too.

On the other side the XDG-standard tries to apply, well, a standard. Once every application uses this standard and the user get friend of it, it will be more accurate. But there are many applications out there which do not follow this standard as well... e.g. firefox (.mozilla), thunderbird and gnupg, just to name some popular.

But i think the pain to implement this would be hard.

Revision history for this message

SirVer (sirver) wrote on 2017-10-21:

#4

> On the other side the XDG-standard tries to apply, well, a standard.

:). https://xkcd.com/927/

It is not the only standard for unix directory layouts - the first one dates back to solaris days and states: everything in .dotfiles. We just followed this.

Revision history for this message

TiborB (tiborb95) wrote on 2017-10-22:

#5

If it was only for config files, I would not care, but for savegames, replay and even wai files, it would mean obscure location and few clicks more to get there...

Revision history for this message

kaputtnik (franku) wrote on 2017-10-22:

#6

> :). https://xkcd.com/927/

:-D

Revision history for this message

Lucki (lucki1) wrote on 2017-10-22:

#7

I understand your concern, but XDG has a few key advantages over dotfiles.
- No predefined paths. The user can decide where his or her data is located.
- No cluttered home directory. Some selectors will automatically show dotfiles, finding the files you want will be easier.
- A shared storage location for data. Application data does not have to be searched for, as these are no longer located in different places. This also benefits a backup.
- Resetting the settings and keeping the application data at the same time becomes easier, as there is a clear separation.
Here's some reading about it:
- https://wiki.gnome.org/Initiatives/GnomeGoals/XDGConfigFolders
- https://ploum.net/207-modify-your-application-to-use-xdg-folders/

To your arguments:
- Just because you've always done something like this so far doesn't mean you have to keep doing it that way, even though there might be a better way to do it. Especially since the dotfiles are based on a programming error: https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwWwN9jp
- XDG is designed for Unix and does not need to be transferred to Windows. For sure compiler switches are already used, they could be extended.
- You can change the variables so that your data remains in your home directory, all in one folder and easily accessible. This is an advantage of XDG, you can customize the paths.

I am unfortunately unable to judge how difficult it is to make the adjustments, but I would ask you to include the above arguments in your decision.

Revision history for this message

SirVer (sirver) wrote on 2017-10-23:

#8

> - No predefined paths. The user can decide where his or her data is located.

This is also added complexity which needs to be understood. Besides, setting $HOME to any other directory is fine, it is only used for initial location of your shell after login (which can be overwridden in your .profile) and the location of your .dotfiles. That is also what HOME is meant to be.

> - No cluttered home directory. Some selectors will automatically show dotfiles, finding the files you want will be easier.

This argument is that some software ignores an older standard, so we require a newer standard to work around their short comings.

> - A shared storage location for data. Application data does not have to be searched for, as these are no longer located in different places. This also benefits a backup.

I do parse this argument - do not understand.

> - Just because you've always done something like this so far doesn't mean you have to keep doing it that way, even though there might be a better way to do it. Especially since the dotfiles are based on a programming error: https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwWwN9jp

Don't fix it if it ain't broke. Half-assing a new thing just makes the situation worse. XDG is > 7 years old, the poor adoption signifies (to me) that it fixes a problem that just doesn't pain enough people.

> - XDG is designed for Unix and does not need to be transferred to Windows. For sure compiler switches are already used, they could be extended.

see, but dotfiles directory transfers splendid to other OSes. No code complexity needed.

I see that you care deeply about this and I respect this. I feel pretty strongly in the other direction and am annoyed at software that uses anything but .dotfiles under UNIX.

Revision history for this message

Nascher (nascher) wrote on 2017-10-31:

#9

> Besides, setting $HOME to any other directory is fine, it is only used for initial location of your shell after login (which can be overwridden in your .profile) and the location of your .dotfiles. That is also what HOME is meant to be.

This adds more complexity to the user, than it will solve. If the user set this to the profile or as standard for every program, then it will only move the home directory elsewhere, but nothing improvable has been added.

I know, that the users can overwrite the environment variables for each program, but I do not think that everybody will love this method. I think the solution targets more the power user.

> Don't fix it if it ain't broke.

Okay, but if a new idea is formed or improvements are available, why not using it?
If we strongly use this, we had stick to the classic “address lists” for finding new web pages,
instead of using search engines, because it “worked”.

Why should I wait until something brakes, instead of giving some cool ideas a try?

> see, but dotfiles directory transfers splendid to other OSes. No code complexity needed.

Can you show me some games, that are using dot files under any Windows system? ;-)
I find my save files in Windows under documents or if the developers are nice, in the
application data directory, where it should be belonged.

On Mac OS systems, they have a different directory for application data too.
Every well-known system has a default, where application data belongs,
but we save all the things on our Home directory with dotfiles?
Sounds not user-friendly in my opinion :-)

My personal view of why some developers are not supporting XDG is, that
some programs are ported from system A to Unix and the developers only ensure,
that the port works. They normally don't know that XDG exists, are lazy or they do not care,
because the Unix systems are not their primary target. (E.g. Firefox, Teamspeak, Factory, ...)

Revision history for this message

GunChleoc (gunchleoc) wrote on 2017-11-01:

#10

I wouldn't be against it if somebody found an elegant implementation for this for all OSses, but I won't be spending any time on this myself. I have a long list of UI, game engine and documentation improvements I'd like to implement first ;)

Revision history for this message

SirVer (sirver) wrote on 2017-11-01:

#11

Download full text (3.2 KiB)

> This adds more complexity to the user, than it will solve. If the user set this to the profile or as standard for every program, then it will only move the home directory elsewhere, but nothing improvable has been added.

I do not get your argument here. This will effectively move your dotfiles into the directory of your choosing, just like XDG

> I think the solution targets more the power user.

XDG does too. The average user will not care where the settings are. Case in point: Mac OS uses a hidden folder called Library in your home dir that is not shown in the finder (explorer) AND dotfiles and most Mac OS users do not know and do not need to care. XDG makes it possible for the power user to define the configuration directories - and I argue the power user can already do this. But this is moot - I cannot make XDG go away anymore, though I very much wish I could.

> Why should I wait until something brakes, instead of giving some cool ideas a try?

I think your arguments are missing the point. We invented search engines because the rest didn't work - and we moved on and EVERYONE uses search engines now. XDG did not manage to do that: It presented new ideas, fragmented the standard space, but did not win over dotfiles. It is the XML of configurations - a bad idea, poorly implemented but unfortunately hard to get rid off. Moving to it seems like the wrong direction to me though.

> Can you show me some games, that are using dot files under any Windows system? ;-)

When I say dotfile, I am not talking about a directory that starts with a dot, I am talking about the concept of a dotfile. And most of them use the concept, Widelands included. The concept is essentially: a) a hardcoded, non-changable base directory b) every data the game writes goes into this base directory.

> Every well-known system has a default, where application data belongs,
but we save all the things on our Home directory with dotfiles?
Sounds not user-friendly in my opinion :-)

Why? Windows does not allow you to change this path, nor does Mac OS. The paths are hidden to the user unless explicitly requested - _exactly_ the same as dotfiles. But nobody ask on Mac for a setting to change ~/Library to ~/MySpecialPlace - why people feel the need for this on Linux is beyond me.

> My personal view of why some developers are not supporting XDG is, that
some programs are ported from system A to Unix and the developers only ensure,
that the port works. They normally don't know that XDG exists, are lazy or they do not care,
because the Unix systems are not their primary target. (E.g. Firefox, Teamspeak, Factory, ...)
Hide

Wait, what? SSH, wget, curl, vim, (x)emacs, bash, lynx, Docker, Dart, gnupg, even gnome2 still uses .gnome2 and has not fully transitioned to xdg. All of these tools are primarily homed on linux, some of them only run on Linux.

I think this discussion has lost merit though - we are arguing if XDG makes sense or not. I think it does not and feel hard coded config paths are the simpler and better solution. Others apparently disagree. For Widelands, the pain of backwards compatibility when moving to xdg is substantial (see for example how neovim users got b...

> This adds more complexity to the user, than it will solve. If the user set this to the profile or as standard for every program, then it will only move the home directory elsewhere, but nothing improvable has been added.

I do not get your argument here. This will effectively move your dotfiles into the directory of your choosing, just like XDG

> I think the solution targets more the power user.

XDG does too. The average user will not care where the settings are. Case in point: Mac OS uses a hidden folder called Library in your home dir that is not shown in the finder (explorer) AND dotfiles and most Mac OS users do not know and do not need to care. XDG makes it possible for the power user to define the configuration directories - and I argue the power user can already do this. But this is moot - I cannot make XDG go away anymore, though I very much wish I could.

> Why should I wait until something brakes, instead of giving some cool ideas a try?

I think your arguments are missing the point. We invented search engines because the rest didn't work - and we moved on and EVERYONE uses search engines now. XDG did not manage to do that: It presented new ideas, fragmented the standard space, but did not win over dotfiles. It is the XML of configurations - a bad idea, poorly implemented but unfortunately hard to get rid off. Moving to it seems like the wrong direction to me though.

> Can you show me some games, that are using dot files under any Windows system? ;-)

When I say dotfile, I am not talking about a directory that starts with a dot, I am talking about the concept of a dotfile. And most of them use the concept, Widelands included. The concept is essentially: a) a hardcoded, non-changable base directory b) every data the game writes goes into this base directory.

>  Every well-known system has a default, where application data belongs,
but we save all the things on our Home directory with dotfiles?
Sounds not user-friendly in my opinion :-)

Why? Windows does not allow you to change this path, nor does Mac OS. The paths are hidden to the user unless explicitly requested - _exactly_ the same as dotfiles. But nobody ask on Mac for a setting to change ~/Library to ~/MySpecialPlace - why  people feel the need for this on Linux is beyond me.

> My personal view of why some developers are not supporting XDG is, that
some programs are ported from system A to Unix and the developers only ensure,
that the port works. They normally don't know that XDG exists, are lazy or they do not care,
because the Unix systems are not their primary target. (E.g. Firefox, Teamspeak, Factory, ...)
Hide

Wait, what? SSH, wget, curl, vim, (x)emacs, bash, lynx, Docker, Dart, gnupg, even gnome2 still uses .gnome2 and has not fully transitioned to xdg. All of these tools are primarily homed on linux, some of them only run on Linux.

I think this discussion has lost merit though - we are arguing if XDG makes sense or not. I think it does not and feel hard coded config paths are the simpler and better solution. Others apparently disagree. For Widelands, the pain of backwards compatibility when moving to xdg is substantial (see for example how neovim users got bitten by nvim no longer looking in the home for the dotfiles) and not worth our time.

Revision history for this message

Nascher (nascher) wrote on 2017-11-04:

#12

> XDG does too. The average user will not care where the settings are. ...

If I am not setting any variables, I know that the config files are under .config/
available and specific files under .local/share. It comes the application directory
like Windows and Mac near, but at least it spams the $HOME not full.

> ... It is the XML of configurations - a bad idea, poorly implemented but unfortunately hard to get rid off. Moving to it seems like the wrong direction to me though ...

This is your opinion, but why the hell should it be difficult?
It tries to manage the dot files mess and tries therefore to give the power users a possibility to manage their Home on their own.

> Why? Windows does not allow you to change this path, nor does Mac OS. The paths are hidden to the user unless explicitly requested - _exactly_ the same as dotfiles. ...

Wrong, you can change the path under the windows systems since Windows 2000.
It thus uses variables in the registry, that can be changed to the user, system, ...

> Wait, what? SSH, wget, curl, vim, (x)emacs, bash, lynx, Docker, Dart, gnupg, ...

I've talked about program ports not directly programs that origins from UNIX and the latest release of Gnome 2 was in 2010 and yes, some new programs does not use this “standard” too.

> For Widelands, the pain of backwards compatibility when moving to xdg is substantial (see for example how neovim users got bitten by nvim no longer looking in the home for the dotfiles) and not worth our time.

Okay, fine.

Revision history for this message

Lucki (lucki1) wrote on 2017-11-19:

#13

Here's a (probably bad) implementation I can come up with. There's still no seperation between the config, data and cache files, but it's better than nothing. It works in my simple tests and moves the folder to the new location if found in home and built with XDG.
The compatibility part look a bit awkward, probably because I don't know better.

To build with XDG give cmake the option -DUSE_XDG.

=== modified file 'CMakeLists.txt'
--- CMakeLists.txt 2017-09-20 11:38:26 +0000
+++ CMakeLists.txt 2017-11-19 16:54:25 +0000
@@ -9,6 +9,11 @@
option(OPTION_BUILD_WEBSITE_TOOLS "Build website-related tools" ON)
option(OPTION_BUILD_TRANSLATIONS "Build translations" ON)

+option(USE_XDG "Follow XDG-Basedir specification" OFF) # Disabled by default
+IF(USE_XDG)
+ ADD_DEFINITIONS(-DUSE_XDG)
+ENDIF(USE_XDG)
+
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR "Build directory and source directory must not be the same.")
endif (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)

=== modified file 'src/io/filesystem/filesystem.cc'
--- src/io/filesystem/filesystem.cc 2017-08-16 13:23:15 +0000
+++ src/io/filesystem/filesystem.cc 2017-11-19 22:04:21 +0000
@@ -168,10 +168,32 @@
  log("None of the directories was useable - falling back to \".\"\n");
#else
#ifdef HAS_GETENV
+#ifdef USE_XDG
+ if (char const* const x = getenv("XDG_DATA_HOME"))
+ homedir = x;
+ else if (char const* const h = getenv("HOME")) {
+ homedir = h;
+ homedir = homedir + "/.local/share";
+ }
+
+ // backward compatibility
+ if (!homedir.empty()) {
+ if (char const* const t = getenv("HOME")) {
+ std::string tmp;
+ tmp = t;
+ tmp = tmp + "/.widelands";
+ RealFSImpl dot(t);
+ RealFSImpl xdg(homedir);
+ if (dot.is_directory(".widelands") && !xdg.is_directory("widelands"))
+ dot.fs_rename(tmp, homedir + "/widelands");
+ }
+ }
+#else
  if (char const* const h = getenv("HOME"))
   homedir = h;
#endif
#endif
+#endif

if (homedir.empty()) {
log("\nWARNING: either we can not detect your home directory "

=== modified file 'src/wlapplication.cc'
--- src/wlapplication.cc 2017-11-06 20:19:56 +0000
+++ src/wlapplication.cc 2017-11-19 14:00:16 +0000
@@ -285,6 +285,8 @@
      should_die_(false),
#ifdef _WIN32
      homedir_(FileSystem::get_homedir() + "\\.widelands"),
+#elif USE_XDG
+ homedir_(FileSystem::get_homedir() + "/widelands"),
#else
      homedir_(FileSystem::get_homedir() + "/.widelands"),
#endif

Here's a (probably bad) implementation I can come up with. There's still no seperation between the config, data and cache files, but it's better than nothing. It works in my simple tests and moves the folder to the new location if found in home and built with XDG.
The compatibility part look a bit awkward, probably because I don't know better.

To build with XDG give cmake the option -DUSE_XDG.

=== modified file 'CMakeLists.txt'
--- CMakeLists.txt	2017-09-20 11:38:26 +0000
+++ CMakeLists.txt	2017-11-19 16:54:25 +0000
@@ -9,6 +9,11 @@
 option(OPTION_BUILD_WEBSITE_TOOLS "Build website-related tools" ON)
 option(OPTION_BUILD_TRANSLATIONS "Build translations" ON)
 
+option(USE_XDG "Follow XDG-Basedir specification" OFF) # Disabled by default
+IF(USE_XDG)
+    ADD_DEFINITIONS(-DUSE_XDG)
+ENDIF(USE_XDG)
+
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
   message(FATAL_ERROR "Build directory and source directory must not be the same.")
 endif (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)

=== modified file 'src/io/filesystem/filesystem.cc'
--- src/io/filesystem/filesystem.cc	2017-08-16 13:23:15 +0000
+++ src/io/filesystem/filesystem.cc	2017-11-19 22:04:21 +0000
@@ -168,10 +168,32 @@
 	log("None of the directories was useable - falling back to \".\"\n");
 #else
 #ifdef HAS_GETENV
+#ifdef USE_XDG
+	if (char const* const x = getenv("XDG_DATA_HOME"))
+		homedir = x;
+	else if (char const* const h = getenv("HOME")) {
+		homedir = h;
+		homedir = homedir + "/.local/share";
+	}
+	
+	// backward compatibility
+	if (!homedir.empty()) {
+		if (char const* const t = getenv("HOME")) {
+			std::string tmp;
+			tmp = t;
+			tmp = tmp + "/.widelands";
+			RealFSImpl dot(t);
+			RealFSImpl xdg(homedir);
+			if (dot.is_directory(".widelands") && !xdg.is_directory("widelands"))
+				dot.fs_rename(tmp, homedir + "/widelands");
+		}
+	}
+#else
 	if (char const* const h = getenv("HOME"))
 		homedir = h;
 #endif
 #endif
+#endif
 
 	if (homedir.empty()) {
 		log("\nWARNING: either we can not detect your home directory "

=== modified file 'src/wlapplication.cc'
--- src/wlapplication.cc	2017-11-06 20:19:56 +0000
+++ src/wlapplication.cc	2017-11-19 14:00:16 +0000
@@ -285,6 +285,8 @@
      should_die_(false),
 #ifdef _WIN32
      homedir_(FileSystem::get_homedir() + "\\.widelands"),
+#elif USE_XDG
+     homedir_(FileSystem::get_homedir() + "/widelands"),
 #else
      homedir_(FileSystem::get_homedir() + "/.widelands"),
 #endif

Revision history for this message

GunChleoc (gunchleoc) wrote on 2017-11-20:

#14

I'm worried about how to support a patch like that - for example, if people compile with the new option and then forget that they've done it, their files won't be moved back to the default .widelands dir the next time that they compile with our compile script.

Also, do Windows and Mac have a $HOME dir? If not, your patch will probably break stuff.

Revision history for this message

Lucki (lucki1) wrote on 2017-11-20:

#15

You're right, moving the folder was a bad idea. Now the patch looks for an already existing folder and uses it if it's available. So the dotfolder is always the default.
To prevent errors on Mac and Windows I've excluded them in the CMakeLists (I hope that works that way). There shouldn't break anything on these two operating systems but I can't test it and make sure.
I've tested this again on Linux and it seems to work like expected in my little testing.

=== modified file 'CMakeLists.txt'
--- CMakeLists.txt 2017-09-20 11:38:26 +0000
+++ CMakeLists.txt 2017-11-20 14:49:03 +0000
@@ -9,6 +9,11 @@
option(OPTION_BUILD_WEBSITE_TOOLS "Build website-related tools" ON)
option(OPTION_BUILD_TRANSLATIONS "Build translations" ON)

+option(USE_XDG "Follow XDG-Basedir specification" OFF) # Disabled by default
+IF(USE_XDG AND NOT APPLE AND NOT WIN32)
+ ADD_DEFINITIONS(-DUSE_XDG)
+ENDIF(USE_XDG AND NOT APPLE AND NOT WIN32)
+
if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
message(FATAL_ERROR "Build directory and source directory must not be the same.")
endif (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)

=== modified file 'src/io/filesystem/filesystem.cc'
--- src/io/filesystem/filesystem.cc 2017-08-16 13:23:15 +0000
+++ src/io/filesystem/filesystem.cc 2017-11-20 14:49:42 +0000
@@ -168,8 +168,28 @@
  log("None of the directories was useable - falling back to \".\"\n");
#else
#ifdef HAS_GETENV
+#ifndef USE_XDG
  if (char const* const h = getenv("HOME"))
   homedir = h;
+#else
+ if (char const* const h = getenv("HOME")) {
+ if (char const* const x = getenv("XDG_DATA_HOME")) {
+ homedir = x;
+ }
+ else {
+ homedir = h;
+ homedir = homedir + "/.local/share";
+ }
+ homedir = homedir + "/widelands";
+
+ // backward compatibility: use dotfolder if it exists
+ RealFSImpl dot(h);
+ if (dot.is_directory(".widelands")) {
+ homedir = h;
+ homedir = homedir + "/.widelands";
+ }
+ }
+#endif
#endif
#endif

=== modified file 'src/wlapplication.cc'
--- src/wlapplication.cc 2017-11-06 20:19:56 +0000
+++ src/wlapplication.cc 2017-11-20 14:28:05 +0000
@@ -285,6 +285,8 @@
      should_die_(false),
#ifdef _WIN32
      homedir_(FileSystem::get_homedir() + "\\.widelands"),
+#elif USE_XDG
+ homedir_(FileSystem::get_homedir()),
#else
      homedir_(FileSystem::get_homedir() + "/.widelands"),
#endif

You're right, moving the folder was a bad idea. Now the patch looks for an already existing folder and uses it if it's available. So the dotfolder is always the default.
To prevent errors on Mac and Windows I've excluded them in the CMakeLists (I hope that works that way). There shouldn't break anything on these two operating systems but I can't test it and make sure.
I've tested this again on Linux and it seems to work like expected in my little testing.

=== modified file 'CMakeLists.txt'
--- CMakeLists.txt	2017-09-20 11:38:26 +0000
+++ CMakeLists.txt	2017-11-20 14:49:03 +0000
@@ -9,6 +9,11 @@
 option(OPTION_BUILD_WEBSITE_TOOLS "Build website-related tools" ON)
 option(OPTION_BUILD_TRANSLATIONS "Build translations" ON)
 
+option(USE_XDG "Follow XDG-Basedir specification" OFF) # Disabled by default
+IF(USE_XDG AND NOT APPLE AND NOT WIN32)
+    ADD_DEFINITIONS(-DUSE_XDG)
+ENDIF(USE_XDG AND NOT APPLE AND NOT WIN32)
+
 if (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
   message(FATAL_ERROR "Build directory and source directory must not be the same.")
 endif (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)

=== modified file 'src/io/filesystem/filesystem.cc'
--- src/io/filesystem/filesystem.cc	2017-08-16 13:23:15 +0000
+++ src/io/filesystem/filesystem.cc	2017-11-20 14:49:42 +0000
@@ -168,8 +168,28 @@
 	log("None of the directories was useable - falling back to \".\"\n");
 #else
 #ifdef HAS_GETENV
+#ifndef USE_XDG
 	if (char const* const h = getenv("HOME"))
 		homedir = h;
+#else
+	if (char const* const h = getenv("HOME")) {
+		if (char const* const x = getenv("XDG_DATA_HOME")) {
+			homedir = x;
+		}
+		else {
+			homedir = h;
+			homedir = homedir + "/.local/share";
+		}
+		homedir = homedir + "/widelands";
+		
+		// backward compatibility: use dotfolder if it exists
+		RealFSImpl dot(h);
+		if (dot.is_directory(".widelands")) {
+			homedir = h;
+			homedir = homedir + "/.widelands";
+		}
+	}
+#endif
 #endif
 #endif

=== modified file 'src/wlapplication.cc'
--- src/wlapplication.cc	2017-11-06 20:19:56 +0000
+++ src/wlapplication.cc	2017-11-20 14:28:05 +0000
@@ -285,6 +285,8 @@
      should_die_(false),
 #ifdef _WIN32
      homedir_(FileSystem::get_homedir() + "\\.widelands"),
+#elif USE_XDG
+     homedir_(FileSystem::get_homedir()),
 #else
      homedir_(FileSystem::get_homedir() + "/.widelands"),
 #endif

Revision history for this message

GunChleoc (gunchleoc) wrote on 2017-11-20:

#16

+#elif USE_XDG
+ homedir_(FileSystem::get_homedir()),
#else

This will dump all out data directly into .local/share - better make a widelands subdirectory.

Revision history for this message

Lucki (lucki1) wrote on 2017-11-20:

#17

It already has a widelands subdirectory. I had to pull it in filesystem.cc because I have no idea how to check for the home directory in application.cc in a elegant way to distinguish between "/.widelands" and "/widelands".

+ homedir = h;
+ homedir = homedir + "/.local/share";
+ }
+ homedir = homedir + "/widelands";

--------

+ if (dot.is_directory(".widelands")) {
+ homedir = h;
+ homedir = homedir + "/.widelands";

Lucki (lucki1) on 2019-08-28

Changed in widelands:
status:	New → Fix Committed

Revision history for this message

GunChleoc (gunchleoc) wrote on 2019-09-16:

#18

Migrated to https://github.com/widelands/widelands/issues/3217

Changed in widelands:
status:	Fix Committed → Won't Fix

widelands

Follow XDG basedir specification

Bug Description

Related branches

Other bug subscribers

Remote bug watches