SDL file storage (multiplatform problems)

SDL Development
1

Hey,
I just want to mention that every single SDL app I’ve used in Mac OS X has created an invisible file in my home directory. Now while tcsh does the same thing, it’s expected that all graphical apps store files in the following manner:

  • Preferences go in ‘~/Library/Preferences/’ and are visible files.

  • User-added (or managed) support files like plug-ins, scripts, textures, etc. go in ‘~/Library/Application Support/AppName/’ and are visible. Typically categorized like:

‘~/Library/Application Support/AppName/Plug-Ins/’
’~/Library/Application Support/AppName/Scripts/'
etc.

  • Immutable resource files go in the application bundle like ‘Appname.app/Contents/Resources/’

In MacOS the story is similar except there is one global location for Preferences and Application Support. Carbon provides one API which works with both systems, but you can use POSIX paths in OS X if you wish.

The problem is every single SDL app is doing things it’s own way. How about defining a set of directories so SDL apps behave property on the host platform, as well as a filename prefix (like “.” in Linux to make prefs invisible)? I don’t think I should have to contact every single author of an SDL app individually and explain this all over again.

2

Interesting point. Though… it seems almost unworkable. The problem is,
that the UNIX convention is the dotfile. .magnwasprogram.rc or what not.
Windows convention is the .ini file. Obviously, you see OSX’s preference.
Perhaps an XML based preference file solution is in order… or maybe a
wrapper library for SDL? As for this … I don’t want to say ‘deal with it’…
but… Apple did choose to use a Unix like core. I’m sorry they don’t wish
to follow Unix conventions in that kind, but I hardly find this to be an SDL
issue as much as a programmer discretion issue.

In truth… you should be able to change this file yourself in your source
trees.

Jarrod HenryOn Friday 03 August 2001 22:22, you wrote:

Hey,
I just want to mention that every single SDL app I’ve used in Mac OS X has
created an invisible file in my home directory. Now while tcsh does the
same thing, it’s expected that all graphical apps store files in the
following manner:

  • Preferences go in ‘~/Library/Preferences/’ and are visible files.

  • User-added (or managed) support files like plug-ins, scripts, textures,
    etc. go in ‘~/Library/Application Support/AppName/’ and are visible.
    Typically categorized like:

‘~/Library/Application Support/AppName/Plug-Ins/’
’~/Library/Application Support/AppName/Scripts/'
etc.

  • Immutable resource files go in the application bundle like
    ’Appname.app/Contents/Resources/’

In MacOS the story is similar except there is one global location for
Preferences and Application Support. Carbon provides one API which works
with both systems, but you can use POSIX paths in OS X if you wish.

The problem is every single SDL app is doing things it’s own way. How about
defining a set of directories so SDL apps behave property on the host
platform, as well as a filename prefix (like “.” in Linux to make prefs
invisible)? I don’t think I should have to contact every single author of
an SDL app individually and explain this all over again.

3

I just want to mention that every single SDL app I’ve used in Mac OS X
has

…

  • Preferences go in ‘~/Library/Preferences/’ and are visible files.
  • User-added (or managed) support files like plug-ins, scripts,
    textures,

etc. go in ‘~/Library/Application Support/AppName/’ and are visible.

Interesting point. Though… it seems almost unworkable. The problem is,
that the UNIX convention is the dotfile. .magnwasprogram.rc or what not.
Windows convention is the .ini file. Obviously, you see OSX’s preference.

I’m not familiar with MacOS X but I’ve used Linux for a quite some time and
I’d say dot-files in the home must go. They are fine if you don’t use that
much apps and every app makes only one file… I’d suggest that SDL provided
a way to query suitable filename for a file. A simple API like this:

char* SDL_GetFilenameForPreference(char* appName,char* prefName);
char* SDL_GetFilenameForPlugin(char* appName,char* pluginName);
char* SDL_GetFilenameForScript(char* appName,char* scriptName);

char* SDL_GetPathForPreference(char* appName);
char* SDL_GetPathForPlugin(char* appName);
char* SDL_GetPathForScript(char* appName);

Where appName would be name of the application like “Awesome FPS” and
prefName, pluginName, scriptName should be like “Settings”, “Antialiasing”,
“Rocket Jump”.

For example:

SDL_GetFilenameForPreference(“Awesome FPS”,“Settings”);

would return string

‘C:\Program Files\Awesome FPS\Settings.pref’ under Windows,
’/.etc/awesome-fps/settings.pref’ under Linux (or
’/.awesome-fps.settings.rc’ if you must) and
’/Library/Preferences/Awesome FPS/Settings under MacOS X.

Returned string should be malloc()ed by SDL and free()d by user. Note that I
replaced space with ‘-’ and converted all characters to lower case for
Linux.

GetPath*() should return directory for application to scan itself for files
of this kind. In this case it’s up to the developer to make sure that loaded
files are valid. (There could be a text file in the same directory the
plugins are)

The problem is, where should the plugins and kind should go to under UNIX
(and MacOS and w2k if correcly setup, not run as adminitrator)?
~/.etc/appname/plugins or /usr/lib/share/appname/plugins? Should there be
user specific plugins in addition to system wide? The same applies to prefs
etc. This is where Mozilla got it wrong - try to install Mozilla in a
multiuser system…

  • Mikko

PS. If you really want to follow the MS way you should include company name
in addition to app name, but I think it’s better this way. End user will
know “Quake” instead of “id” and the directory name should be accordingly.
If some company really wants to make it’s name visible it should use company
name in app name (“Microsoft XYZ”?).