SFML community forums
General => Feature requests => Topic started by: Kolja 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 ;-)):
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.
-
For now I'll say no, but I'll probably consider this kind of features in the future, when SFML 2 is out and the most important/big tasks that I plan to add are implemented.
-
physfs does some of this (at least for the write directory part)
-
physfs does some of this (at least for the write directory part)
Thanks, I didn't know about that one. Even has a good license :-)
I'll take a look at it and see what I can get out of it.
-
OK, physfs doesn't do very much of what I need. The only platform specific directory I can query gives me /Users/myusername, which is far from where I would and should be putting written files.
-
Shouldn't you... you know... ask the player where to install?
I personally loathe games that just install themselves in some folder of their own choice. (doubly so since my %AppData% is on an SSD with very limited amount of space - I prefer to have all my games apart from the one I'm currently playing on another physical drive entirely).
I can see the usefulness of the stuff you're suggesting if it only has the purpose of providing a good first guess though. That being said, writing an installer for any given OS is probably better to do outside of SFML though (like InstallShield etc for Windows).
-
I have nothing against making it configurable, and plan to do so, but that first guess is what I need.
Apart from that, I strongly think that the way modern OSs (OS X, Linux, Win >= Vista) organize files makes a lot of sense for a majority of the users. Meaning that there is a read-only directory for static files and executables (no accidental changes to files by users/users' processes), and a central place for configurations and other written data (easy transition to a new machine). The way it's done in general is the same across all platforms here, though it may be %appdata% and My Documents in two seperate directories or ~/ and ~/Library in one directory.
If you are a more advanced user wanting to do something different, sure, that's fine, but instead of hating the software, why not just create a symlink from the preconfigured place to where you want it to be? I do that all the time.
But as I said in the beginning, I like configurability and want to implement it. And installers should ask you where to install (though I like OS X' way of doing applications even more, but I'm biased here :-)). But I wasn't even talking about the installer, my proposition is completely post-install related.
To think a little further down the road, I could see OSs moving away from directory structures and to applications (think iOS), at least hiding the implementation for the majority of users. That would make it even more necessary to ask the OS where a certain type of file needs to be placed.
-
Shouldn't you... you know... ask the player where to install?
I personally loathe games that just install themselves in some folder of their own choice. (doubly so since my %AppData% is on an SSD with very limited amount of space - I prefer to have all my games apart from the one I'm currently playing on another physical drive entirely).
I can see the usefulness of the stuff you're suggesting if it only has the purpose of providing a good first guess though. That being said, writing an installer for any given OS is probably better to do outside of SFML though (like InstallShield etc for Windows).
Well, this is really only an issue in windows. In linux (and macosx if I am not mistaken) there are standard directories for everything.
For example a linux game:
executable in /usr/bin (depending on distribution this could also be /usr/games)
data in /usr/share/appname (depending on distribution this could also be /usr/share/games/appname )
and user files /home/username/.appname
You typically don't get to choose where things go. Of course since everything uses the same structure you can distribute your partition mount points smartly.
And show me a single windows game where you can decide separately where data and executable go ;) And properly designed games will use the user directories as well for saving (saving anywhere else is just wrong on a multiuser system...)
-
Shouldn't you... you know... ask the player where to install?
I personally loathe games that just install themselves in some folder of their own choice. (doubly so since my %AppData% is on an SSD with very limited amount of space - I prefer to have all my games apart from the one I'm currently playing on another physical drive entirely).
I can see the usefulness of the stuff you're suggesting if it only has the purpose of providing a good first guess though. That being said, writing an installer for any given OS is probably better to do outside of SFML though (like InstallShield etc for Windows).
Well, this is really only an issue in windows. In linux (and macosx if I am not mistaken) there are standard directories for everything.
For example a linux game:
executable in /usr/bin (depending on distribution this could also be /usr/games)
data in /usr/share/appname (depending on distribution this could also be /usr/share/games/appname )
and user files /home/username/.appname
You typically don't get to choose where things go. Of course since everything uses the same structure you can distribute your partition mount points smartly.
And show me a single windows game where you can decide separately where data and executable go ;) And properly designed games will use the user directories as well for saving (saving anywhere else is just wrong on a multiuser system...)
FULL ACK.
Windows does get better with time though. Well, they're only a few decades late to the game, right? ;-) Maybe they will someday switch to a Unix base as well, so we have a working useable command prompt on all systems (not serious, but one can dream).
"Real" OS X apps (meaning not CLI) don't separate executable and data though, everything is in one folder. The OS treats this folder as a file though, and you can run it everywhere (even from trash, as far as I know). It is a convention to put these bundles into ~/Applications or /Applications though, and most applications offer to do that for you if you if you run them from somewhere else.
-
Maybe they will someday switch to a Unix base as well, so we have a working useable command prompt on all systems (not serious, but one can dream).
But Windows already has working and usable shell (and it's IMO better than anything POSIX-compliant at the moment)...
-
In my experience bash has always been preferable to cmd.exe, but I haven't really used the latter in quite some time. Does Windows have something like grep/ack installed by now? Always missed that. Program output is usually less easily machine readable as well (e.g. dir.exe vs ls).
What bothers me more is the missing POSIX compliancy, as there are many really good tools for these. But I guess in the end it comes down to preference as well, and we shouldn't let this thread degenerate into discussions about that.
But I'd be happy to see what I'm missing if you happen to have a good tutorial at hand. I'd try it out the next time I happen to use a Windows system.
-
Sorry if I skipped an important note in one post but I haven't got a lot of time these days...
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
You might want to have a look at what I've done (http://goo.gl/30wWy)
-
Sorry if I skipped an important note in one post but I haven't got a lot of time these days...
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
You might want to have a look at what I've done (http://goo.gl/30wWy)
I assume you mean the CPD part of the link? Thanks for that, that's at least a way to do it for now. I'm not sure getenv() is the best way to go here though. And it doesn't solve the problem for the readonly directory, but that is mostly a OS X problem as the CWD for a graphically started application is / there for some reason.
-
Yes, that's cpd. It works pretty well but if you know something better than getenv let me know. ;-)
This might also help you with your readonly folder on OS X : http://www.sfml-dev.org/forum/viewtopic.php?p=28142#28142 (I'm not sure if the app bundle is really readonly...)
-
Thanks for the link, but I'm already doing that in a similar way. But that is exactly the problem I mean, you need Cocoa, .mm files and so on, and I think this is a small (and limited) field of objectives where SFML should provide a few helper functions to minimize the need for platform specific code (and what application using SFML doesn't need data files?).
Oh, and no, the Bundle is not read-only, but configuration files shouldn't be stored in there so that the user can delete and reinstall applications and their settings are remembered. But I'm not exactly sure about bundles installed to /Applications that are used by non-admin users. They should be read-only again, but again, not sure there.
And I have something better, at least for OS X:
std::string cfstringToStdString(const CFStringRef cfstr) {
CFIndex bufferLength = 1 + CFStringGetMaximumSizeForEncoding(CFStringGetLength(cfstr), kCFStringEncodingUTF8);
char* buffer = new char[bufferLength];
CFStringGetCString(cfstr, buffer, bufferLength, kCFStringEncodingUTF8);
std::string result = buffer;
delete[] buffer;
return result;
}
std::string getDataPath() {
NSArray* allPaths = NSSearchPathForDirectoriesInDomains(NSApplicationSupportDirectory, NSUserDomainMask, TRUE);
CFStringRef path = (CFStringRef)[allPaths objectAtIndex:0];
return cfstringToStdString(path);
}
That should be the official way to do it.
[edit]
Just to be clear, that snipped needs #import <Cocoa/Cocoa.h> and compilation as an Objective-C(++) file.
-
In my experience bash has always been preferable to cmd.exe
Of course, bash is way better than cmd, in fact, everything is. But I'm not talking about cmd :P
Does Windows have something like grep/ack installed by now?
It doesn't, since there's no need for that: select-string is a PowerShell's builtin ;)
What bothers me more is the missing POSIX compliancy, as there are many really good tools for these.
Windows is not and does not try to be a *nix (Interix notwithstanding).
-
Interesting. Honestly didn't know about that.
But PowerShell doesn't look like the thing that will make my life easier on those machines I use that run Windows. Because it won't be installed. And I wouldn't have the rights to do so.
And I guess it doesn't help the fact that Windows simply wasn't built with a shell in mind. Or does it provide file-based access to settings instead of that abomination that calls itself registry? ;-)
But again, a matter of preference. You are happy with Windows and PS and I am happy with OS X and bash and can feel at home at every Unix and Linux that comes my way, so everything's fine. :-)
-
And I guess it doesn't help the fact that Windows simply wasn't built with a shell in mind. Or does it provide file-based access to settings instead of that abomination that calls itself registry? ;-)
It does, kind of (http://powershell.com/cs/blogs/ebook/archive/2009/03/30/chapter-16-the-registry.aspx) ;)
By the way...
You are happy with Windows and PS
No, I'm not. I think that Windows (or Mac OS, or BSD, or Linux, or anything for that matter) certainly can be far better than it is now.
-
Color me amazed.
After decades, Windows is catching up. Well, guess I'll have to learn using it at some point. From the comparisons I found bash looks a bit more concise, but the differences are minor, which is a good thing.
-
Color me amazed.
After decades, Windows is catching up. Well, guess I'll have to learn using it at some point. From the comparisons I found bash looks a bit more concise, but the differences are minor, which is a good thing.
MS did a lot wrong with previous Windows versions, but Win7 is actually really good IMO