Thoughts on the new filesystem API

Edward_Rudd · August 21, 2013, 12:35am

It’s a nice and welcome addition, however I have a few thoughts on it…

The GetPrefPath seems to inconsistently use org… or rather it is ONLY used on windows… Wouldn’t it make sense to always use “org” if it’s set, and not use it, if NULL is passed?
OS X GetBasePath… yeah I don’t like the return value… as it’s going to return the bundle path… e.g. “MyApplication.app” which is inconsistent with what linux + windows are doing… IMHO it should return the Parent directory… However even that is not really “good enough”… more ideal would be do have a hint set up like SDL_HINT_FILESYSTEM_OSX_USE_RESOURCE_DIR… and if set return resourcePath instead of bundlePath parent…

e.g.

NSBundle *bundle = [NSBundle mainBundle];
NSString dataPath;
const char use_resource = SDL_GetHint(SDL_HINT_FILESYSTEM_OSX_USE_RESOURCE_DIR);
if ( hint && hint[0] == ‘1’) {
dataPath = [bundle resourcePath];
} else {
dataPath = [[bundle bundlePath] stringByDeletingLastPathComponent];
}

char *base = [dataPath UTF8String];

As this follows more closely the two common packaging styles on Mac OS X. Actually in one game I work on (Amnesia series from Frictional Games) I have an extra property in the Info.plist that I fetch to determine where the resource directory is… e.g. either resource dir or bundlePath parent. As we distribute the game both ways… (steam is bundlePath parent, everywhere else is resource path).

Edward Rudd
OutOfOrder.cc
Skype: outoforder_cc
317-674-3296

icculus · August 21, 2013, 1:11am

The GetPrefPath seems to inconsistently use org… or rather it is ONLY used on windows… Wouldn’t it make sense to always use “org” if it’s set, and not use it, if NULL is passed?

The problem is that convention on the other OSes appears to be to NOT
specify an organization.

Everything on my Mac–including Apple’s apps–goes in
“~/Library/Application Support/AppName” … the exceptions appear to be
Google’s apps, which land in …/Google/AppName, and the Doublefine
games that, uh, you ported.

Linux is similar: the XDG spec says it goes in (by default)
~/.local/share/subdir, but it doesn’t specify what “subdir” is…but it
makes sense that it would match what we used to do with all those
dotfiles in $HOME.

On iOS, you don’t even get to write to a common directory, but rather an
app-specific namespace. I assume Android is similar.

That leaves future undefined platforms and Windows. Windows dictates
that you list an organization, so we need this information, which means
it makes sense to make every platform specify it.

OS X GetBasePath… yeah I don’t like the return value… as it’s
going to return the bundle path… e.g. “MyApplication.app” which is
inconsistent with what linux + windows are doing… IMHO it should
return the Parent directory… However even that is not really “good
enough”… more ideal would be do have a hint set up like
SDL_HINT_FILESYSTEM_OSX_USE_RESOURCE_DIR… and if set return
resourcePath instead of bundlePath parent…

Generally speaking, we want the directory where the program is
installed. Knowing the parent of the .app directory isn’t helpful…if
you want your installed data files location, would you rather get
“/Applications/MyGame.app/” or “/Applications/”? On a platform that
makes renaming app icons so easy?

By contrast, on Linux, this would tend to return something like
“/opt/MyGame/”, which matches what you get on the Mac.

As for the hint: I can be persuaded, but I’d rather not do it, because…

Actually in one game I work on (Amnesia series from Frictional
Games) I have an extra property in the Info.plist that I fetch to
determine where the resource directory is… e.g. either resource dir or
bundlePath parent. As we distribute the game both ways… (steam is
bundlePath parent, everywhere else is resource path).

…the usual way I solve this (small .app bundle on the Mac dropped into
the Windows depot), looks something like this:

chdir(SDL_GetBaseDir()); // or whatever we used before SDL.
#ifdef STEAM_BUILD
chdir(“…”);
#else
chdir(“Resources”); // but usually I just put stuff in “.app” dir.
#endif

–ryan.

Edward_Rudd · August 21, 2013, 1:23am

The GetPrefPath seems to inconsistently use org… or rather it is ONLY used on windows… Wouldn’t it make sense to always use “org” if it’s set, and not use it, if NULL is passed?

The problem is that convention on the other OSes appears to be to NOT specify an organization.

Everything on my Mac–including Apple’s apps–goes in “~/Library/Application Support/AppName” … the exceptions appear to be Google’s apps, which land in …/Google/AppName, and the Doublefine games that, uh, you ported.

And I usually do it for games where they are already doing that on other platforms… As usually they have it setup to be Org/App on an existing mac port as well… So consistency rules in that case? There are other games where I don’t do that and put it straight up in the XDG dir.

Linux is similar: the XDG spec says it goes in (by default) ~/.local/share/subdir, but it doesn’t specify what “subdir” is…but it makes sense that it would match what we used to do with all those dotfiles in $HOME.

On iOS, you don’t even get to write to a common directory, but rather an app-specific namespace. I assume Android is similar.

Or Mac OS X in “sandbox mode”… as that works exactly like iOS… the NSSearchPathForDirectoriesInDomains would give you a “private” app data directory in the sandbox, and as such will still work.

That leaves future undefined platforms and Windows. Windows dictates that you list an organization, so we need this information, which means it makes sense to make every platform specify it.

OS X GetBasePath… yeah I don’t like the return value… as it’s
going to return the bundle path… e.g. “MyApplication.app” which is
inconsistent with what linux + windows are doing… IMHO it should
return the Parent directory… However even that is not really “good
enough”… more ideal would be do have a hint set up like
SDL_HINT_FILESYSTEM_OSX_USE_RESOURCE_DIR… and if set return
resourcePath instead of bundlePath parent…

Generally speaking, we want the directory where the program is installed. Knowing the parent of the .app directory isn’t helpful…if you want your installed data files location, would you rather get “/Applications/MyGame.app/” or “/Applications/”? On a platform that makes renaming app icons so easy?

By contrast, on Linux, this would tend to return something like “/opt/MyGame/”, which matches what you get on the Mac.

As for the hint: I can be persuaded, but I’d rather not do it, because…

Actually in one game I work on (Amnesia series from Frictional
Games) I have an extra property in the Info.plist that I fetch to
determine where the resource directory is… e.g. either resource dir or
bundlePath parent. As we distribute the game both ways… (steam is
bundlePath parent, everywhere else is resource path).

…the usual way I solve this (small .app bundle on the Mac dropped into the Windows depot), looks something like this:

chdir(SDL_GetBaseDir()); // or whatever we used before SDL.
#ifdef STEAM_BUILD
chdir(“…”);
#else
chdir(“Resources”); // but usually I just put stuff in “.app” dir.
#endif

–ryan.

Which is kinda icky… as you have platform specific code… where as just having the SDL framework just “get” the data directory… So the code is simpler for all platforms would be ideal.

So developers don’t have to think as much about platform differences… Otherwise this function becomes really useless on OS X (and iOS) as I have to create my own code for “those” platforms… (And I’m assuming you means Contents/Resources )…

Usually I abstract these functions out in games ports as GetDataDir() and GetUserDir(). So I really I would like to see the SDL function replace those… not have to continue to be wrapped by those functions to handle further platform differences… Maybe we add a SDL_GetDataDir() that does the extra “magic” on top of basedir?On Aug 20, 2013, at 9:11 PM, Ryan C. Gordon wrote:

icculus · August 21, 2013, 1:39am

So developers don’t have to think as much about platform differences…
Otherwise this function becomes really useless on OS X (and iOS) as I
have to create my own code for “those” platforms… (And I’m assuming
you means Contents/Resources )…

(oops, yes, Contents/Resources, sorry.)

Just so I’m clear, you’re asking for a hint so you can do this…

 // we put the data files somewhere else here, but only on Mac OS X!
 #if defined(STEAM_BUILD) && defined(__APPLE__)
 SDL_SetHint(SDL_HINT_FILESYSTEM_OSX_USE_RESOURCE_DIR, "1");
 #endif
 std::string mypath = SDL_GetBaseDir();

…instead of this…

 std::string mypath = SDL_GetBaseDir();
 // we put the data files somewhere else, but only on Mac OS X!
 #if defined(STEAM_BUILD) && defined(__APPLE__)
 mypath += "Contents/Resources/";
 #endif

…or am I misunderstanding the problem?

–ryan.

slouken · August 21, 2013, 2:15am

Can we rename GetBaseDir() to GetDataDir()? That makes it more clear what
these are for.

In my head anyway, GetPrefDir() is where you write preferences and save
files.

GetDataDir() is where you load your resources, and on MacOS X this is the
Contents/Resources directory, on Linux this would be /opt/, etc. It
wouldn’t be /usr/local/bin, which is where my game binary is installed.

Or maybe I’m misunderstanding the purposes of the functions?On Tue, Aug 20, 2013 at 6:39 PM, Ryan C. Gordon wrote:

So developers don’t have to think as much about platform differences…

Otherwise this function becomes really useless on OS X (and iOS) as I
have to create my own code for “those” platforms… (And I’m assuming
you means Contents/Resources )…

(oops, yes, Contents/Resources, sorry.)

Just so I’m clear, you’re asking for a hint so you can do this…
// we put the data files somewhere else here, but only on Mac OS X!
#if defined(STEAM_BUILD) && defined(__APPLE__)
SDL_SetHint(SDL_HINT_**FILESYSTEM_OSX_USE_RESOURCE_**DIR, "1");
#endif
std::string mypath = SDL_GetBaseDir();
…instead of this…
std::string mypath = SDL_GetBaseDir();
// we put the data files somewhere else, but only on Mac OS X!
#if defined(STEAM_BUILD) && defined(__APPLE__)
mypath += "Contents/Resources/";
#endif
…or am I misunderstanding the problem?

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · August 21, 2013, 3:13am

Can we rename GetBaseDir() to GetDataDir()? That makes it more clear
what these are for.

“Base” might be the wrong word (although it’s the term we use in
PhysicsFS for this function), but it’s not strictly for data: it’s for
where your program is running, which can mean a lot of things about
where your data is in relation to it. Some examples:

UnrealEngine2 games have their binary in a “System” directory, which is
a child of the root of the game’s installation directory (UE3 moved this
somewhere else, even deeper in subdirectories). Mac games might store
their stuff inside their “.app” folder, or just outside of it for Steam
games using the Windows data depot, or inside it at the
Contents/Resources folder.

What a game does with the string it gets from GetBaseDir() is
game-specific. SDL can’t predict all of these, or even force them to
standardize.

GetDataDir() is where you load your resources, and on MacOS X this is
the Contents/Resources directory, on Linux this would be /opt/,
etc. It wouldn’t be /usr/local/bin, which is where my game binary is
installed.

The problem with reporting Contents/Resources is that you can run apps
outside of an app bundle, Unix-style, and then there is no
Contents/Resources folder. SDL could check for this, but it’s probably
better if the app knows what it needs and appends a string here if
necessary.

For Linux, if there’s a symlink in /usr/local/bin, we’ll still report
where the real binary is…I’m not really sure how to find /opt/
on Linux if the binary itself is really separate in /usr/local/bin, though.

–ryan.On 8/20/13 10:15 PM, Sam Lantinga wrote:

Sik_the_hedgehog · August 21, 2013, 3:20am

2013/8/21, Ryan C. Gordon :

The problem with reporting Contents/Resources is that you can run apps
outside of an app bundle, Unix-style, and then there is no
Contents/Resources folder. SDL could check for this, but it’s probably
better if the app knows what it needs and appends a string here if
necessary.

Doesn’t that mean the code is not fully portable anymore? I mean,
suddenly now the program is required to know about properties specific
to the platform it’s running on, which is the very thing a portable
API is supposed to avoid.

For Linux, if there’s a symlink in /usr/local/bin, we’ll still report
where the real binary is…I’m not really sure how to find /opt/
on Linux if the binary itself is really separate in /usr/local/bin, though.

On the other hand, if the user runs the program from the symlink,
chances are it may also expect the program to behave like it was
running from there… Not sure how this pans out in practice.

icculus · August 21, 2013, 3:30am

Doesn’t that mean the code is not fully portable anymore?

SDL can’t psychically know where your app chooses to store its data.

On the other hand, if the user runs the program from the symlink,
chances are it may also expect the program to behave like it was
running from there… Not sure how this pans out in practice.

There’s a long history Linux games, back to Loki at least, installing a
symlink to some place in your $PATH, so you can launch the game from the
command line without having to know the full location or add every game
to your $PATH.

–ryan.

Sik_the_hedgehog · August 21, 2013, 3:33am

2013/8/21, Ryan C. Gordon :

SDL can’t psychically know where your app chooses to store its data.

A program using the SDL for the filesystem would probably want SDL to
tell it which directories it should use. If the program didn’t then
chances are it wouldn’t be using SDL for that purpose for starters.

icculus · August 21, 2013, 3:50am

A program using the SDL for the filesystem would probably want SDL to
tell it which directories it should use. If the program didn’t then
chances are it wouldn’t be using SDL for that purpose for starters.

Then the existing default will work fine for them.

–ryan.

slouken · August 21, 2013, 5:07am

Fair enough, I withdraw my request.On Tue, Aug 20, 2013 at 8:13 PM, Ryan C. Gordon wrote:

On 8/20/13 10:15 PM, Sam Lantinga wrote:

Can we rename GetBaseDir() to GetDataDir()? That makes it more clear
what these are for.

“Base” might be the wrong word (although it’s the term we use in PhysicsFS
for this function), but it’s not strictly for data: it’s for where your
program is running, which can mean a lot of things about where your data is
in relation to it. Some examples:

UnrealEngine2 games have their binary in a “System” directory, which is a
child of the root of the game’s installation directory (UE3 moved this
somewhere else, even deeper in subdirectories). Mac games might store their
stuff inside their “.app” folder, or just outside of it for Steam games
using the Windows data depot, or inside it at the Contents/Resources folder.

What a game does with the string it gets from GetBaseDir() is
game-specific. SDL can’t predict all of these, or even force them to
standardize.

GetDataDir() is where you load your resources, and on MacOS X this is

the Contents/Resources directory, on Linux this would be /opt/,
etc. It wouldn’t be /usr/local/bin, which is where my game binary is
installed.

The problem with reporting Contents/Resources is that you can run apps
outside of an app bundle, Unix-style, and then there is no
Contents/Resources folder. SDL could check for this, but it’s probably
better if the app knows what it needs and appends a string here if
necessary.

For Linux, if there’s a symlink in /usr/local/bin, we’ll still report
where the real binary is…I’m not really sure how to find /opt/ on
Linux if the binary itself is really separate in /usr/local/bin, though.

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jonathan_Greig · August 21, 2013, 6:11am

Ryan,
It makes much more sense to me to stick a shell script in the PATH that
cd’s to the proper directory first than a symlink. That’s what I have
always done for launching from the terminal. Then simply create a .desktop
file that executes the shell script and your paths within the application
will always be consistent. In linux, simply clicking/double clicking the
actual binary in the file browser may mess this up if your binary is
unzipped from a tar into your user directory for example, which helps
explain why the .desktop/shellscript combo are a good idea. Is there a
better way with symlinks? Using them in the manner you speak of has never
panned out well for me.

If you look at the shell scripts in witty-examples ubuntu package that
launch the examples, I think you will find what you are looking for in
terms of the binary location and the location where it was executed from.
See this file in that package: /usr/lib/Wt/examples/hello/hello

Pasted below also:

#!/bin/sh
PATH_TO_SCRIPT=$(cd ${0%/} && echo $PWD/${0##/})
EXAMPLEPREFIX=dirname "$PATH_TO_SCRIPT"
EXAMPLESUBDIR=hello
EXAMPLESUBDIRFROMPREFIX=lib/Wt/examples/hello
PREFIX=echo $EXAMPLEPREFIX | sed s,$EXAMPLESUBDIRFROMPREFIX,,g
PATH=$PREFIX/bin:$PATH LD_LIBRARY_PATH=$PREFIX/lib:$LD_LIBRARY_PATH
DYLD_LIBRARY_PATH=$PREFIX/lib:$DYLD_LIBRARY_PATH $EXAMPLEPREFIX/hello.wt
–docroot $EXAMPLEPREFIX/ --approot $EXAMPLEPREFIX/ --http-port 8080
–http-addr 0.0.0.0 $@

Hope that helps some

Jonathan

icculus · August 21, 2013, 8:18am

It makes much more sense to me to stick a shell script in the PATH that
cd’s to the proper directory first than a symlink.

It’s also an option, probably a better one.

What the Loki games would do, near startup, is figure out where the real
binary was from argv[0]: if it had a ‘/’ in it, you knew exactly where
the file was, and if not, they searched the $PATH for it. This was
before Linux offered /proc/self/exe.

You can see exactly what Loki’s code did here (look for “loki_initpaths”)…

https://svn.icculus.org/*checkout*/loki_utils/trunk/loki_paths.c?content-type=text%2Fplain

–ryan.

slouken · August 21, 2013, 9:21am

Wow, looking at that code takes me back… :)On Wed, Aug 21, 2013 at 1:18 AM, Ryan C. Gordon wrote:

It makes much more sense to me to stick a shell script in the PATH that

cd’s to the proper directory first than a symlink.

It’s also an option, probably a better one.

What the Loki games would do, near startup, is figure out where the real
binary was from argv[0]: if it had a ‘/’ in it, you knew exactly where the
file was, and if not, they searched the $PATH for it. This was before Linux
offered /proc/self/exe.

You can see exactly what Loki’s code did here (look for
“loki_initpaths”)…

https://svn.icculus.org/***checkout*/loki_utils/trunk/**
loki_paths.c?content-type=**text%2Fplainhttps://svn.icculus.org/*checkout*/loki_utils/trunk/loki_paths.c?content-type=text%2Fplain

–ryan.

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Axel_Dorfler · August 21, 2013, 12:25pm

How about adding a GetDataDirectory() that actually assumes some standard per
platform, as opposed to GetBaseDirectory() (and thus being able to take
Contents/Resources into account on OS X)? Whether an application chooses to use
it or not is not relevant, as SDL would at least provide the means to use
standard locations per platform.
Or am I missing something?

Bye,
? ?Axel.> On August 21, 2013 at 5:30 AM “Ryan C. Gordon” wrote:

Doesn’t that mean the code is not fully portable anymore?
SDL can’t psychically know where your app chooses to store its data.

john_skaller · August 21, 2013, 12:37pm

Doesn’t that mean the code is not fully portable anymore?

SDL can’t psychically know where your app chooses to store its data.

Yes it can. I’m not completely sure what the filesystem API is for,
but guessing from the conversation, I would suggest something like:

Provide default locations for various stuff eg
plugins
game resources
saved games
config data
Provide a function call like:

int SDL_set_default_locations (SDL_RWOps *);

which reads a configuration file that sets these variables if the defaults
are not right. This means a single master configuration file can be used
to configure your application’s filesystem view, the rest of the application
then proceeds in a platform independent manner using the filesystem API.

The actual filename can be got from the command line or an environment
variable or whatever.

With this setup it may be better to provide the following API instead of
the current one (or as well as it):

char const *SDL_get_location (char const *abstract_location_name);

This uses a text string for the location name. The advantage is that if
the setup file in (2) is read it can provide any extra non-standard
directory locations the application requires.On 21/08/2013, at 1:30 PM, Ryan C. Gordon wrote:

–
john skaller
@john_skaller
http://felix-lang.org

Jared_Maddox · August 22, 2013, 3:32am

Message-ID: <521413D5.7050109 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

OS X GetBasePath… yeah I don’t like the return value… as it’s
going to return the bundle path… e.g. “MyApplication.app” which is
inconsistent with what linux + windows are doing… IMHO it should
return the Parent directory… However even that is not really “good
enough”… more ideal would be do have a hint set up like
SDL_HINT_FILESYSTEM_OSX_USE_RESOURCE_DIR… and if set return
resourcePath instead of bundlePath parent…

Generally speaking, we want the directory where the program is
installed. Knowing the parent of the .app directory isn’t helpful…if
you want your installed data files location, would you rather get
“/Applications/MyGame.app/” or “/Applications/”? On a platform that
makes renaming app icons so easy?

By contrast, on Linux, this would tend to return something like
“/opt/MyGame/”, which matches what you get on the Mac.

Message-ID:
<CACC3sbFEuL8BKVVS6r8_z=SvP9DGY2j0o6NCQQUngGkdTFz31Q at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

Can we rename GetBaseDir() to GetDataDir()? That makes it more clear what
these are for.

In my head anyway, GetPrefDir() is where you write preferences and save
files.

GetDataDir() is where you load your resources, and on MacOS X this is the
Contents/Resources directory, on Linux this would be /opt/, etc. It
wouldn’t be /usr/local/bin, which is where my game binary is installed.

Or maybe I’m misunderstanding the purposes of the functions?

Message-ID: <52143070.6090200 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Can we rename GetBaseDir() to GetDataDir()? That makes it more clear
what these are for.

“Base” might be the wrong word (although it’s the term we use in
PhysicsFS for this function), but it’s not strictly for data: it’s for
where your program is running, which can mean a lot of things about
where your data is in relation to it. Some examples:

four separate directories:

Installation directory
Application Data directory
User Data directory
Application Invocation directory

And on Windows, I think all four might be applicable (though I’m not
really sure about #4, don’t use the Windows API enough for that, and
don’t REALLY do multi-user at all).

GetDataDir() is where you load your resources, and on MacOS X this is
the Contents/Resources directory, on Linux this would be /opt/,
etc. It wouldn’t be /usr/local/bin, which is where my game binary is
installed.

The problem with reporting Contents/Resources is that you can run apps
outside of an app bundle, Unix-style, and then there is no
Contents/Resources folder. SDL could check for this, but it’s probably
better if the app knows what it needs and appends a string here if
necessary.

For Linux, if there’s a symlink in /usr/local/bin, we’ll still report
where the real binary is…I’m not really sure how to find /opt/
on Linux if the binary itself is really separate in /usr/local/bin, though.

If the program was invoked from /opt/ then you’d want the
invocation directory. But, of course, that means you need to be able
to get at it.> Date: Tue, 20 Aug 2013 21:11:49 -0400

From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] Thoughts on the new filesystem API
Date: Tue, 20 Aug 2013 19:15:39 -0700
From: Sam Lantinga
To: SDL Development List
Subject: Re: [SDL] Thoughts on the new filesystem API
Date: Tue, 20 Aug 2013 23:13:52 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] Thoughts on the new filesystem API
On 8/20/13 10:15 PM, Sam Lantinga wrote:
From my perspective, the above three snippets actually describe up to

Date: Wed, 21 Aug 2013 00:20:40 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Thoughts on the new filesystem API
Message-ID:
<CAEyBR+X3RrYShHcMCKmYzLK4=SHU00QmN+P7cFNPthfwVfjyLA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2013/8/21, Ryan C. Gordon :

For Linux, if there’s a symlink in /usr/local/bin, we’ll still report
where the real binary is…I’m not really sure how to find /opt/
on Linux if the binary itself is really separate in /usr/local/bin,
though.

On the other hand, if the user runs the program from the symlink,
chances are it may also expect the program to behave like it was
running from there… Not sure how this pans out in practice.

If you store your data inside entire directories instead of individual
files then it could make sense, otherwise I can’t think of anything
sensible for the majority of programs to do other than either error
out, ignore it, or pop up a “select file” screen. This is more useful
for utilities than anything else… though I suppose it would be
appropriate for a SDL image viewer app?

Date: Wed, 21 Aug 2013 22:37:37 +1000
From: john skaller
To: SDL Development List
Subject: Re: [SDL] Thoughts on the new filesystem API
Message-ID:

Content-Type: text/plain; charset=us-ascii

On 21/08/2013, at 1:30 PM, Ryan C. Gordon wrote:

Doesn’t that mean the code is not fully portable anymore?

SDL can’t psychically know where your app chooses to store its data.

Yes it can. I’m not completely sure what the filesystem API is for,
but guessing from the conversation, I would suggest something like:

Provide default locations for various stuff eg
plugins
game resources
saved games
config data

Provide a function call like:

int SDL_set_default_locations (SDL_RWOps *);

which reads a configuration file that sets these variables if the defaults
are not right. This means a single master configuration file can be used
to configure your application’s filesystem view, the rest of the
application
then proceeds in a platform independent manner using the filesystem API.

The actual filename can be got from the command line or an environment
variable or whatever.

With this setup it may be better to provide the following API instead of
the current one (or as well as it):

char const *SDL_get_location (char const *abstract_location_name);

This uses a text string for the location name. The advantage is that if
the setup file in (2) is read it can provide any extra non-standard
directory locations the application requires.

I, for one, like this idea, but I have a question:
Are you willing to provide the needed data structure(s) under the zlib
license? As I best recall, Mason has previously suggested something
that required a map structure, and it got vetoed for a specific
reason: a desire to keep avoidable dependencies out of SDL.
Dependencies on X11 headers are not easily avoided, but why should
there be a dependence on an external library for a data structure? It
isn’t like it’ll need to change to keep up with changes in an OS api.
So, I think that in order for this to get in, at a minimum the data
structure required for it would have to be inside of the SDL 2
code-base, rather than external to it.

icculus · August 22, 2013, 4:26am

four separate directories:

Installation directory

Application Data directory

User Data directory

Application Invocation directory

Let’s not over-complicate this. In practice, it’s only two things
(“where do I read?” and “where do I write?”).

char const *SDL_get_location (char const *abstract_location_name);
I, for one, like this idea, but I have a question:

The goal isn’t to build an abstract means to configure the way the
system thinks about file layout, the goal is to understand where files
go, as dictated by the standards for that platform, using
platform-specific APIs behind the scenes that obtain this information so
the app doesn’t have to.

If you don’t want an API to tell you exactly where the OS would like
files to go, just put them wherever you want. Adding a config system
seems like serious overkill. If the user wanted to configure this in a
global way, the app wouldn’t want to see those details exposed, and
they’d probably just want you to put the files where the system already
expects them, anyway.

–ryan.> From my perspective, the above three snippets actually describe up to

Sik_the_hedgehog · August 22, 2013, 5:08am

2013/8/22, Jared Maddox :

Application Invocation directory

Isn’t that just the current directory?

2013/8/22, Ryan C. Gordon :

Let’s not over-complicate this. In practice, it’s only two things
(“where do I read?” and “where do I write?”).

Already got bitten by this before by PhysicsFS because user settings
end up with different paths for reading and for writing. Let’s not be
stupid about this.

It’s indeed probably still more complex than it needs to be, though.
The semantics are more like “where is my data?” (assets) and “where is
the user data?” (settings). Probably a third one to get the home
directory, but that’s not what we’re arguing about right now.

Sik_the_hedgehog · August 22, 2013, 5:10am

Whoops, sorry for the empty e-mail (clicked the wrong thing). But
yeah, now I see where the list comes from, you need separate
directories for global settings and user-specific settings. So yeah,
that indeed makes it three directories (the fourth item is still
pointless though, you don’t care from where your program runs after
all).