SDL_wtf (aka SDL_path) proposal

Peter_Hanely · February 6, 2006, 4:45pm

The easiest way to get standard path info on at least some OSs is from env vars. A sampling from my windoze/cygwin system:

APPDATA = 'C:\Documents and Settings\Owner\Application Data’
USERPROFILE = 'C:\Documents and Settings\Owner’
HOMEDRIVE = 'C:'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files’
PROGRAMFILES = 'C:\Program Files’
PWD = '/home/Owner’
HOMEPATH = '\Documents and Settings\Owner’
HOME = '/home/Owner’
TEMP = '/cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp’
SYSTEMDRIVE = 'C:'
SYSTEMROOT = 'C:\WINDOWS’
WINDIR = ‘C:\WINDOWS’

And the perl script I used to dump vars, as a set doesn’t work quite right here:
#!/usr/bin/perl

printenv

foreach $key (keys %ENV)
{ print “$key = '”, $ENV{$key}, “’\n”;
}

The biggest hastle I see is the relevant vars being different on different OSs.

Bill_Kendrick · February 6, 2006, 7:57pm

I’d like to propose a new add-on library for SDL. I’ve jokingly called
it “SDL_wtf”, for “where’s the file?” or “where’re the files?”, but
I think “SDL_path” might be a less inappropriate name. ;^)

The idea is that an SDL-based app might be interested in where to store
its configuration or data files.

Taking Tux Paint as an example:

On Linux:
- global config is in “/etc/tuxpaint/tuxpaint.conf” (or there’bouts),
- user-specific config is in “~/.tuxpaintrc”,
- and the user’s data files are stored in “~/tuxpaint/”
On Windows:
- user-specific config is in
  C:\Documents and Settings{username}\Application Data\TuxPaint
  (exact path depends on version of Windows, its locale, and other
  settings that I’d rather not worry about myself)
- and the user’s data files are currently stored in the same place
  (although “My Documents\TuxPaint” might make more sense)
On Mac OS X:
- user-specific config is currently stored in
  "/Users/{username}/.tuxpaintrc" (which is NOT really the Mac-way!)
- and the user’s data files are stored in
  "/Users/{username}/Library/Preferences/tuxpaint/"
  (which is Mac-friendly)
On BeOS:
- [I don’t know off-hand!]

Since no doubt there are other apps out there that might be interested
in things like “where should I save my config file?” and “is there a global
config file I should read first?” and “where should the user’s data go?”
(e.g., saved-games, levels, etc.), I’d like to propose an add-on library
be created.

(This would probably be a small enough chunk of code that it could be
part of SDL itself, but I’ll just go under the assumption that some folks
out here will hollar “bloat!” :^) )

I’d be happy to begin putting something together, based on what’s currently
in Tux Paint, and letting other-OS-knowledgable folks have at it.
(e.g., a SourceForge.net or Berlios.de project… or if Sam, et al would
be willing, something living in libsdl.org’s CVS repository.)

(The eventual plan would be to remove the existing code from Tux Paint
and use this lib. instead. :^) )

Comments?–
-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

Torsten_Giebl · February 6, 2006, 8:03pm

Hello !

Since no doubt there are other apps out there that might be interested
in things like “where should I save my config file?” and “is there a
global config file I should read first?” and “where should the user’s data
go?” (e.g., saved-games, levels, etc.), I’d like to propose an add-on
library be created.

(This would probably be a small enough chunk of code that it could be
part of SDL itself, but I’ll just go under the assumption that some folks
out here will hollar “bloat!” :^) )

I’d be happy to begin putting something together, based on what’s
currently in Tux Paint, and letting other-OS-knowledgable folks have at
it. (e.g., a SourceForge.net or Berlios.de project… or if Sam, et al
would be willing, something living in libsdl.org’s CVS repository.)

(The eventual plan would be to remove the existing code from Tux Paint
and use this lib. instead. :^) )

I would like something like that,
it can make a coders life
easier. It would be also usefull
to add a function to this SDL_wtf
to ask where the current running exe
is saved. Many people esp. on Windows
like have everything in one dir.

So that when you don`t like
the app anymore, just delete the
whole directory like in the old DOS times.
With the just dragging xyxy.app this is
also on OSX very popular.

CU

Steaphan_Greene · February 6, 2006, 11:58pm

I’d like to propose a new add-on library for SDL. I’ve jokingly called
it “SDL_wtf”, for “where’s the file?” or “where’re the files?”, but
I think “SDL_path” might be a less inappropriate name. ;^)

The idea is that an SDL-based app might be interested in where to store
its configuration or data files.

[…]

This has been discussed here before, but nothing came of it (at least as
far as I know). I think this is a good idea and would love to see this
become a part of SDL itself, or at least a supported extensions, in some
form or another.On Mon, Feb 06, 2006 at 11:57:37AM -0800, Bill Kendrick wrote:

–
Steaphan Greene
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060206/670752e6/attachment.pgp

Alex_Volkov · February 7, 2006, 1:38am

cal at splitreflection.com wrote:

The easiest way to get standard path info on at least some OSs is from
env vars. A sampling from my windoze/cygwin system:
APPDATA = 'C:\Documents and Settings\Owner\Application Data’
USERPROFILE = ‘C:\Documents and Settings\Owner’
[snip]
The biggest hastle I see is the relevant vars being different on
different OSs.

And the vars above do not exist on Windows 95 in single-user mode.

-Alex.

Mike_Powell · February 7, 2006, 2:54am

cal at splitreflection.com wrote:

The easiest way to get standard path info on at least some OSs is from env vars. A sampling from my windoze/cygwin system:

APPDATA = 'C:\Documents and Settings\Owner\Application Data’
USERPROFILE = 'C:\Documents and Settings\Owner’
HOMEDRIVE = 'C:'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files’
PROGRAMFILES = 'C:\Program Files’
PWD = '/home/Owner’
HOMEPATH = '\Documents and Settings\Owner’
HOME = '/home/Owner’
TEMP = '/cygdrive/c/DOCUME~1/Owner/LOCALS~1/Temp’
SYSTEMDRIVE = 'C:'
SYSTEMROOT = 'C:\WINDOWS’
WINDIR = ‘C:\WINDOWS’

And the perl script I used to dump vars, as a set doesn’t work quite right here:
#!/usr/bin/perl

printenv

foreach $key (keys %ENV)
{ print “$key = '”, $ENV{$key}, “’\n”;
}

The biggest hastle I see is the relevant vars being different on different OSs.

Beyond the fact that the environment variables are different on each OS,
I don’t believe there is a platform-independent way of accessing these
variables through C/C++ (which seems to be far and away the most common
language used for SDL). The idea of SDL is to abstract all the basic
platform-specific stuff so you don’t have to worry about it. It makes
sense to me that this is the sort of platform-specific thing that SDL
could easily abstract.

What I would suggest is not a whole package, but just a single simple
function, like:

char* SDL_ConfigPath(void);

That will return a string containing the root path into which one should
stick global config files.

For any other file i/o, I would highly suggest a library by the name of
PhysFS. It creates a sort of abstract file system of the same sort as
that used in the Quake engines, which is very useful for any sort of
game development. I’ve been using it for my engine project, and it’s
brilliant. You can find more info on it here: http://icculus.org/physfs/

I think it would be reasonable for SDL to abstract this sort of
functionality, as directory navigation is an important feature required
for many games, and is completely platform dependent. As long as PhysFS
is around to handle it, it’s not a very urgent feature, but it would be
nice.

Andras_Salamon · February 7, 2006, 5:35am

Sounds like a great idea. For The Battle for Wesnoth we ended up coding
exactly such a set of routines, to handle Unix/Mac OS X/Windows/BeOS.
For some ideas, see
http://svn.gna.org/viewcvs/wesnoth/trunk/src/filesystem.hpp
http://svn.gna.org/viewcvs/wesnoth/trunk/src/filesystem.cpp
(the source is C++, alas). This also provides routines for OS-independent
listing of files in a directory, for instance.

Being able to use a library would have been grand.

– Andras Salamon @Andras_SalamonOn Mon, Feb 06, 2006 at 11:57:37AM -0800, Bill Kendrick wrote:

The idea is that an SDL-based app might be interested in where to store
its configuration or data files.

slouken · February 7, 2006, 8:15am

What I would suggest is not a whole package, but just a single simple
function, like:

char* SDL_ConfigPath(void);

That will return a string containing the root path into which one should
stick global config files.

For any other file i/o, I would highly suggest a library by the name of
PhysFS. It creates a sort of abstract file system of the same sort as
that used in the Quake engines, which is very useful for any sort of
game development. I’ve been using it for my engine project, and it’s
brilliant. You can find more info on it here: http://icculus.org/physfs/

Actualy, I’d prefer this sort of functionality be added to something like
PhysFS. The issue is complicated by the fact that there are lots of types
of config paths and requirements, depending on the system and the design
of the game config files, but this should take care of the usual case.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

icculus · February 7, 2006, 10:31am

Actualy, I’d prefer this sort of functionality be added to something like
PhysFS. The issue is complicated by the fact that there are lots of types
of config paths and requirements, depending on the system and the design
of the game config files, but this should take care of the usual case.

PhysicsFS already does this.

And on some platforms, namely Windows, you have to really jump through
some serious hoops to get this information (including calling
LoadLibrary() on system DLLs that don’t necessarily exist on Win95,
etc). If your app needs it, cut and paste it from physfs (the license
allows this).

Also, I’m sure we could find lots of other tasks for which we should
reserve the name “SDL_wtf”.

–ryan.

David_MacCormack · February 7, 2006, 8:04pm

Actualy, I’d prefer this sort of functionality be added to something like
PhysFS. The issue is complicated by the fact that there are lots of types
of config paths and requirements, depending on the system and the design
of the game config files, but this should take care of the usual case.

PhysicsFS already does this.

And on some platforms, namely Windows, you have to really jump through some
serious hoops to get this information (including calling LoadLibrary() on
system DLLs that don’t necessarily exist on Win95, etc).

Exactly. I ran across the exact same problem when I wrote fnkdat
(http://www.maccormack.net/~djm/fnkdat). Win95 (actually, specific
versions of shfolder.dll) doesn’t understand the concept of per-user
configurations. You have to load the library and query the DLL to see
if the SHGetFolderPath() function is available, and fallback to a
reasonable default if it does not.

DaveOn Tue, 7 Feb 2006, Ryan C. Gordon wrote:

Bill_Kendrick · February 7, 2006, 9:08pm

Tux Paint would not want an ‘abstract’ file system, because kids/parents
would want to hunt down and use the files outside of Tux Paint (e.g.,
in an email program or word processor).

Additionally, files may need to be stored off the local system
(e.g., on a networked filesystem in a school’s computer lab).

Finally, I was imagining that some apps may want to store files
in the ‘user’s home directory’ on a Windows/Linux/Mac system, but that
location might need to be /vmu/a1/ (the little memory card that you stick
inside your game controller) on a DreamCast, for example…

Note: I’m not familiar with PhysFS, so if these are not issues with it,
please feel free to smack me. :)On Mon, Feb 06, 2006 at 06:54:07PM -0800, Mike Powell wrote:

For any other file i/o, I would highly suggest a library by the name of
PhysFS. It creates a sort of abstract file system of the same sort as
that used in the Quake engines, which is very useful for any sort of
game development. I’ve been using it for my engine project, and it’s
brilliant. You can find more info on it here: http://icculus.org/physfs/

–
-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

icculus · February 8, 2006, 12:41am

Note: I’m not familiar with PhysFS, so if these are not issues with it,
please feel free to smack me.

PhysFS imposes other restrictions at the API level that makes it bad for
a general Open File Dialog Box, but you can just yank the code from its
"platform" directory for homedir detection.

–ryan.

Bill_Kendrick · February 8, 2006, 12:49am

Crap! How the hell did I forget about fnkdat!?!? I’ve even used it
(in an unreleased project at work).

:^)

So this is defintitely what I should be looking at.

I suppose I should encourage others in the SDL community to provide David
with patches or details about {insert their favorite platform here}.

Sorry David. Obviously I need to think for about 5mins before suggesting
things. :)On Tue, Feb 07, 2006 at 03:04:30PM -0500, David MacCormack wrote:

Exactly. I ran across the exact same problem when I wrote fnkdat
(http://www.maccormack.net/~djm/fnkdat). Win95 (actually, specific
versions of shfolder.dll) doesn’t understand the concept of per-user
configurations. You have to load the library and query the DLL to see
if the SHGetFolderPath() function is available, and fallback to a
reasonable default if it does not.

–
-bill! Tux Paint 2006 wall calendar,
bill at newbreedsoftware.com CDROM, bumper sticker & apparel
http://www.newbreedsoftware.com/ http://www.cafepress.com/newbreedsw

Bob_Pendleton · February 8, 2006, 6:29pm

Exactly. I ran across the exact same problem when I wrote fnkdat
(http://www.maccormack.net/~djm/fnkdat). Win95 (actually, specific
versions of shfolder.dll) doesn’t understand the concept of per-user
configurations. You have to load the library and query the DLL to see
if the SHGetFolderPath() function is available, and fallback to a
reasonable default if it does not.

Crap! How the hell did I forget about fnkdat!?!? I’ve even used it
(in an unreleased project at work).

:^)

So this is defintitely what I should be looking at.

I suppose I should encourage others in the SDL community to provide David
with patches or details about {insert their favorite platform here}.

Sorry David. Obviously I need to think for about 5mins before suggesting
things.

Just because it already exists is no reason not to turn it into a
standard part of SDL. This library addresses a common problem faced by
many, if not all, developers using SDL. Not to mention that having it on
the SDL web site right next to SDL_Image and so on makes it much more
likely that people will find it and use it. Imagine trying to find a
library that does what Ryan proposed using your favorite search engine?
Nearly impossible.

So, please, I don’t care what source base you start with, just get it a
prominent place on the SDL web site.

	Bob PendletonOn Tue, 2006-02-07 at 16:49 -0800, Bill Kendrick wrote:

On Tue, Feb 07, 2006 at 03:04:30PM -0500, David MacCormack wrote:

–
±-------------------------------------+

Bob Pendleton: writer and programmer +
email: Bob at Pendleton.com +
web: www.GameProgrammer.com +
www.Wise2Food.com +
nutrient info on 7,000+ common foods +
±-------------------------------------+

David_MacCormack · February 9, 2006, 6:32pm

Crap! How the hell did I forget about fnkdat!?!? I’ve even used it
(in an unreleased project at work).

:^)

So this is defintitely what I should be looking at.

I suppose I should encourage others in the SDL community to provide David
with patches or details about {insert their favorite platform here}.

That’d be great. I applied the patch you sent me in April, and I’d be
happy to accept patches to add support for additional platforms.

Sorry David. Obviously I need to think for about 5mins before suggesting
things.

:).

I just added fnkdat to the “Libraries” section of the SDL website. Maybe
a Wiki/FAQ entry with links to PhysicsFS and fnkdat would make sense? The
question does seem to be frequently asked :).

DaveOn Tue, 7 Feb 2006, Bill Kendrick wrote: