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.