Page 1 of 1

Dotfile Madness

PostPosted: 16 Jun 2019, 11:57
by dulsi
LWN had a quote from this blog. I did not know of XDG Base Directory Standard. While I don't consider the proliferation of dot files to be a problem, the standard is a good idea. I'll have to incorporate that into my games. I had started creating .identical to store information for my games but Troll Bridge still uses .troll.

Re: Dotfile Madness

PostPosted: 16 Jun 2019, 13:08
by fluffrabbit
TBH I don't know where to find my settings and saves, but in my user folder I have quite a few dotfolders for various games. You can't expect all those necrotic developers to fix the situation.

Re: Dotfile Madness

PostPosted: 17 Jun 2019, 08:38
by Lyberta
Deleted.

Re: Dotfile Madness

PostPosted: 17 Jun 2019, 09:08
by fluffrabbit
You're including a lot of POSIX-specific stuff. I'm not trying to play devil's advocate, but surely there's a way to uniformly access an application-specific folder on Windows, Android, iOS, etc. Even Web Storage can probably function as a virtual user settings folder if filesystem emulation (see: Emscripten) is used.

EDIT: Wait, no. I'm so retarded. The only sane way is to use non-Unix/POSIX/Linux-like system and put Linux into VM or container. Linux was never sane to begin with.

You edited right before I decided to post. Yeah, don't use Linux-specific stuff. A VM though, I dunno. There is a video on YouTube called The Thirty Million Line Problem in which the Handmade Hero guy rambles about ISAs and doing away with operating systems. Not 100% related, but when I think of VMs, Docker, etc. I cringe. That stuff is too bloated in current implementations.

Re: Dotfile Madness

PostPosted: 17 Jun 2019, 09:27
by Lyberta
Deleted.

Re: Dotfile Madness

PostPosted: 17 Jun 2019, 10:10
by fluffrabbit
Windows uses NTFS to hide things. Dotfiles are more robust because they are filesystem-agnostic. As for naming conventions, it's pretty subjective. I agree that /usr is a stupid name. It's not /home/username, it's a system folder. Why have a system folder that's pronounced "user" on a multi-user system? It's nuts.

I can see that you have tackled the platform abstraction problem head-on. I am not qualified to criticize any of that, but it looks cool. I don't search GitLab and I'm not fond of the GPL, so under normal circumstances I probably wouldn't take notice, but since you pointed it out I think that whatever FTZ does, it's a step in the right direction.

Re: Dotfile Madness

PostPosted: 18 Jun 2019, 20:15
by sago007
I did write a C++ library to abstract the differences between the desktop operating systems: https://github.com/sago007/PlatformFolders
It goes a bit further and also implements the XDG user directories (Documents, Pictures etc) which seems to be something a lot of programs does not do properly. Java and Mono both returns $HOME when asking for the Documents folder.

I do think it is easier when implementing a new program. I can't imagine the amount of scripts that will be broken if ".ssh" moves and ".profile" is needed to actually define the environment. However I do not see why modern programs like Atom or TrenchBroom does not respect it.

For OpenArena I have been looking into moving away from ".openarena" but I have to keep a symlink for a very long migration period to not make all documentation out of date.

Re: Dotfile Madness

PostPosted: 18 Jun 2019, 20:31
by fluffrabbit
That's awesome! One point of confusion (not with these abstractions, but with the Linux way of doing things in general) is the difference between XDG_CONFIG_HOME and XDG_DATA_HOME. I assume they are both settings folders for the apps.

Re: Dotfile Madness

PostPosted: 18 Jun 2019, 20:37
by GunChleoc
Settings would go into config, other user data like savegames would go into data.

Re: Dotfile Madness

PostPosted: 18 Jun 2019, 21:09
by sago007
If in doubt I would put it into XDG_DATA_HOME. I would only put things into XDG_CONFIG_HOME if the files are meant to be human editable. On Windows I map both into Roaming.
I see XDG_CONFIG_HOME as more useful for tools than games. Most games will need a data folder and it might make sense to keep all user files together.

On Windows there seems to be some confusion between "Roaming" and "Local". I map XDG_CACHE_HOME to "Local". I see "Local" as the cache/log dir for data that does not need back-up.

Re: Dotfile Madness

PostPosted: 19 Jun 2019, 04:31
by fluffrabbit
Confusion is definitely the problem. I would want to keep savegames with settings for a game. I have no idea about "Roaming" and "Local". Ideally the folder setup on every computer in the world would just be .cache and .appdata, and that's it.

Re: Dotfile Madness

PostPosted: 09 Jul 2019, 17:02
by dulsi
Updated Troll Bridge to use XDG_DATA_HOME. It automatically copies the old save files to the new location. It doesn't delete the old .troll directory in case of problems.

A nice side benefit of doing this is that I noticed boost::filesystem functions are in the C++17 standard. The randomization code was added in C++11 so Troll Bridge no longer needs boost. I then put boost back in for the Windows version because the cross compiler on Fedora is older and doesn't support the filesystem header. I did lose the boost randomization code and the filesystem functions are similar enough I was able to just use a namespace alias at the start of the file instead of two implementations.

Re: Dotfile Madness

PostPosted: 09 Jul 2019, 17:54
by fluffrabbit
Great, but AFAIK the C++17 filesystem API is mostly just good for enumerating files, dealing with symlinks, etc. I haven't used it yet. In the case of Linux, XDG_DATA_HOME should be an environment variable accessible from plain old C, and pre-C++17 streams could be used for files. Windows uses environment variables as well. What I'm hinting at is that more cross-platform support without the need for newer compiler features or large libraries is a good design goal.

Re: Dotfile Madness

PostPosted: 09 Jul 2019, 18:26
by dulsi
fluffrabbit {l Wrote}:Great, but AFAIK the C++17 filesystem API is mostly just good for enumerating files, dealing with symlinks, etc. I haven't used it yet. In the case of Linux, XDG_DATA_HOME should be an environment variable accessible from plain old C, and pre-C++17 streams could be used for files. Windows uses environment variables as well. What I'm hinting at is that more cross-platform support without the need for newer compiler features or large libraries is a good design goal.

I'm not trying to make a solution for everyone. If that is what you want, seems like sago007's PlatformFolders may be a good solution.

Re: Dotfile Madness

PostPosted: 09 Jul 2019, 18:34
by fluffrabbit
dulsi {l Wrote}:
fluffrabbit {l Wrote}:Great, but AFAIK the C++17 filesystem API is mostly just good for enumerating files, dealing with symlinks, etc. I haven't used it yet. In the case of Linux, XDG_DATA_HOME should be an environment variable accessible from plain old C, and pre-C++17 streams could be used for files. Windows uses environment variables as well. What I'm hinting at is that more cross-platform support without the need for newer compiler features or large libraries is a good design goal.

I'm not trying to make a solution for everyone. If that is what you want, seems like sago007's PlatformFolders may be a good solution.

It is a good solution, but for a game I probably wouldn't even use that, I'd try to cram the bare minimum functionality into 200 lines of code or less. You used to support DOS. I'm not saying you should, but I'm on kind of an oldschool kick right now, I dunno.

Related: High-level infrastructure may be doomed.

Re: Dotfile Madness

PostPosted: 09 Jul 2019, 22:28
by sago007
Another thing that does annoy me is that using the environment variables on Windows fails for international characters. This may be better in the future now that Windows 10 finally supports UTF-8 but I still think it will take a while for all the legacy systems to reach EOL.

At the moment you need the wide characters API on Windows which prevents most of the basic C and C++ libraries.

I use SDL2 and PhysicsFS to handle files and system calls across platforms. They both converts all char-strings to UTF-8.

Re: Dotfile Madness

PostPosted: 10 Jul 2019, 00:19
by fluffrabbit
Can't you use C++ utf16 strings or a vector of uint16_t? All you have to do is convert your utf8 strings to codepoints and you're good to go. Since enumerating files from the filesystem is less common, you probably only need one-way conversion. If things are more fiddly than that, maybe double up the characters by doing reinterpret_cast<char*>( MyWideString.data() ) or something similar.

Re: Dotfile Madness

PostPosted: 10 Jul 2019, 08:53
by Lyberta
Deleted.

Re: Dotfile Madness

PostPosted: 11 Jul 2019, 17:25
by Julius
Moderator notice, split off UTF discussion.