Show Posts
1
Feature requests / File System Support, Part II
« on: March 03, 2011, 05:04:19 pm »
Hi,
while playing around with SFML again for some time now, I would like to have another try at making a file system support request (previous one I found isn't from me though).
As far as I can tell, any reasonably sized project needs access to two directories to behave well on the three main OSs (Win, Lin, Mac - sorry BSD guys ;-)):
The thing is, the OS usually provides methods of getting these directories in a reliable and future-proof way, but these methods are highly OS specific and a pain to code in cross-platform projects. I did this for myself in OS X for now (found a snippet on the net), but that means using Objective-C++ code in my projects, which in turn meant having to use specific compiler flags and so on and was generally a PITA to get working.
This can not be done via boost::filesystem by the way, b::f should be used for path translation and all that, but it's still pretty platform agnostic when it comes to where data is/should be actually stored.
What I would propose is simply having a class providing static functions like GetResourceDir() and GetWriteableDir() that only return a String containing absolute paths to these directories for the given platform the project was compiled on. The rest (checking if the WriteableDir exists already, if not creating it, ...) should still be up to the user / b::f.
So, comments, what do you think? I don't think this would be too much outside SFML's current scope.
while playing around with SFML again for some time now, I would like to have another try at making a file system support request (previous one I found isn't from me though).
As far as I can tell, any reasonably sized project needs access to two directories to behave well on the three main OSs (Win, Lin, Mac - sorry BSD guys ;-)):
- Some sort of resource directory for files included with the project - sprites, textures, models, you know what I mean.
This would probably be ./ under Windows (i.e. the directory the executable lives in), the Resources folder inside the Mac OS X application bundle, or (I'm not too sure here) somewhere in /usr/local for Linux.
- A writeable directory for written config files, savegames and so on.
This again might be %appdata%/MyProjectName (or in the user's My Files/My Games or what's it called) under Windows, Library/Application Support/MyProjectName for Mac OS X, and ~/.myprojectname for Linux
The thing is, the OS usually provides methods of getting these directories in a reliable and future-proof way, but these methods are highly OS specific and a pain to code in cross-platform projects. I did this for myself in OS X for now (found a snippet on the net), but that means using Objective-C++ code in my projects, which in turn meant having to use specific compiler flags and so on and was generally a PITA to get working.
This can not be done via boost::filesystem by the way, b::f should be used for path translation and all that, but it's still pretty platform agnostic when it comes to where data is/should be actually stored.
What I would propose is simply having a class providing static functions like GetResourceDir() and GetWriteableDir() that only return a String containing absolute paths to these directories for the given platform the project was compiled on. The rest (checking if the WriteableDir exists already, if not creating it, ...) should still be up to the user / b::f.
So, comments, what do you think? I don't think this would be too much outside SFML's current scope.