SFML 2.0 Mac OSX in App Bundle

[Kolja]

Hey, isn't this the same question/whish I had some time ago? It's great news that GetResourceDirectory() will exist, that means I can scrap my code for that. Getting Obj-C and C++ to interact (and compile in the first place) wasn't fun at all.

But what about a writeable directory? Will you provide GetApplicationSupportDirectory() as well? Or did I miss it in this thread? Anyhow, you can't write to the resource directory, and finding that directory needs Obj-C code as well (due to internationalisation issues), so it would really make sense.

[Hiura]

It's great news that GetResourceDirectory() will exist

It is already available on the git repository. Get the last version, install the xcode 4 templates and you go!  :wink:

But what about a writeable directory? Will you provide GetApplicationSupportDirectory() as well?

This feature won't be present with the xcode 4 templates because it is not related to the application bundle. Anyway, you can get this function from my svn here : http://svn.tuxfamily.org/viewvc.cgi/hblog_svn/cpd/trunk/ (Download GNU tarball), the documentation is available here : http://hiura.tuxfamily.org/online/doc/cpd/ . It's a cross platform thing so you can use the same header on Mac, Unix and Windows. And because it's a header-only-libriary no installation is required.  

[Kolja]

It's great news that GetResourceDirectory() will exist

It is already available on the git repository. Get the last version, install the xcode 4 templates and you go!  :wink:

That's great!

But what about a writeable directory? Will you provide GetApplicationSupportDirectory() as well?

This feature won't be present with the xcode 4 templates because it is not related to the application bundle. Anyway, you can get this function from my svn here : http://svn.tuxfamily.org/viewvc.cgi/hblog_svn/cpd/trunk/ (Download GNU tarball), the documentation is available here : http://hiura.tuxfamily.org/online/doc/cpd/ . It's a cross platform thing so you can use the same header on Mac, Unix and Windows. And because it's a header-only-libriary no installation is required.  

Not the way I would do it, and probably not the way it should be done, but from what I can gather ~/Library gets internationalized for display only, the real path stays the same, so it will work at least until OS XI ;-)

What I had done previously was this:

Code: [Select]

const sf::String& FileManagerMacOsX::internalWriteableDirectoryPath() {
  if (writeableDirectoryDefined)
    return writeableDirectory;
 
  NSArray* allPaths = NSSearchPathForDirectoriesInDomains(
    NSApplicationSupportDirectory, NSUserDomainMask, TRUE);
  CFStringRef path = (CFStringRef)[allPaths objectAtIndex:0];
  writeableDirectory = cfstringToSfString(path) + "/Duergar/";
  writeableDirectoryDefined = true;
  return writeableDirectory;
}
But that needs separate compilation again and is no fun to get to work in a C++ project.
As I said, I think we had this discussion already, and I think it would make sense especially when you include a GetResourceDirectory(), but if you don't agree I can't force you ;-)

[Hiura]

As I said, I think we had this discussion already, and I think it would make sense especially when you include a GetResourceDirectory(), but if you don't agree I can't force you ;-)

I would be very happy to agree but you first need to convince me (which is sometimes hard I admit :roll: ).

The thing is I have to put some limit to the function I add to the templates. I don't want that the templates become a mess because there are too many functions added.

Currently, I have decided to limit these functions to whose are related to application bundle. 'Application Data Directory' is not in this category. That's why I'm not very convinced I should add it.

[Kolja]

I just noticed I misread your posts, I thought you were adding the function to OSX SFML, not to a pregenerated source file. I'd prefer the former.

As for the convincing part, my arguments still stay the same:

* You definitely need GetResourceDirectory() if you want to deploy on OS X and use any kind of data file, and and GetWriteableDirectory() if you want to save anything to the hard disk. It is similar for Windows and Linux if you want your application to be a good citizen on those platforms.

* There are default locations for both on all major platforms.

* Getting their values "the right way" requires platform specific code, and in the case of OS X even the use of another language (assuming most SFML users write C++).

* When you use SFML for what (I again assume) is the most common project, something game-like or at least an application that does its drawing itself and doesn't need a OS-supported menu bar, you don't need any platform specific code for the entire application and still got every kind of functionality (graphics, sound, input, networking, file access) at your disposal,

except for finding your own friggin' files.

* There are no good fire-and-forget (or include-and-link-to in this case) solutions for this problem, apart from libraries doing magic without asking you (like SFML did).

* I often read the argument of high or low level here, but isn't the task finding out what will be the most needed/used functions and supplying them instead of clamoring to some arbitrary measure of leveled-ness?
[/list]
I hope I don't sound too harsh, or else I'm sorry. I just had the questionable pleasure of working with SFML without those functions and spend days getting all of this working and compiling, and I don't get why everyone will have to suffer through the same.
And lastly, what about people starting development on Linux and wanting to port their application to OS X? Instead of cross-compiling, they will have to get the necessary functions from the XCode templates and somehow stitch it all together.

I admire the work you do here, but this a decision I just don't get. Especially since the cost of providing the functions are so much less for SFML than for SFML-using applications.

OK, rant done. ;-)