SFML community forums

General => General discussions => Topic started by: zenkimoto on March 02, 2011, 07:24:14 am

Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 02, 2011, 07:24:14 am
Hello,

I realize that the instructions say to create a new C++ command line project and include the dynamic/static libraries from cmake.  I got everything to work doing it that way.  However, is it possible to build a bundle with 2.0?  

I tried to create a new Cocoa project, modify it to include all the SFML libraries.  So far so good.  Everything works except for my working directory...  I have to reference:  "TestSFML.app/Contents/Resources/testimage.png" instead of just "testimage.png".  It seems that the working directory is where the bundle is located.  Anyways, I could be doing it all wrong....

I'm really just wondering if it is possible to build a bundle with 2.0 or do I just need to do a chdir() system call.  

Thanks!
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 04, 2011, 07:19:41 pm
I've got two news for your.

First, the good news : Yes, you can do that.

Seconde, the good news : you can use this function to get the resource directory path :

Code: [Select]
// RessourcesDirectory.hpp

#ifndef RESSOURCESDIRECTORY_H
#define RESSOURCESDIRECTORY_H

#include <string>

std::string GetRPath(void);

#endif


Code: [Select]
// RessourcesDirectory.mm

#include "RessourcesDirectory.hpp"
#import <Foundation/Foundation.h>

std::string GetRPath(void) {
    // Get the resources dir path.
std::string rpath;
NSBundle* bundle = [NSBundle mainBundle];
if (bundle == nil) {
NSLog(@"bundle is nil... thus no resources path can be found.");
} else {
NSString* path = [bundle resourcePath];
rpath = [path UTF8String] + std::string("/");
}
   
    return rpath;
}


Just add these two files into your project (watch out : the second file extension has to be .mm).

Have fun.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 04, 2011, 10:43:41 pm
Hiura:

Thanks for your reply!!  Haha, so it's all around good news?


I will give that a try.  Thanks for the code to get the path of the resources directory.  

So, do we have to include this function to get the resource path from SFML 2.0+?  The project template from 1.6 did not require this.  Did 1.6 change the working directory to the resources folder on a OS X build?
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 05, 2011, 12:00:15 am
Quote from: "zenkimoto"
Did 1.6 change the working directory to the resources folder on a OS X build?


Yup. But I dunno whether Hiura wishes to do so for SFML 2.0.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 05, 2011, 08:23:09 am
I haven't made up my mind yet but currently I don't think I'll change the working dir. The problem is – of that I know – if there is at least one application which needs the 'correct' working dir then I should not change it.

But you still can argue with me and make me change my mind.  :wink:
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 05, 2011, 12:56:20 pm
To my mind:

The Resources directory should be the working directory because the equivalent to the data directory next to the Windows executable IS the Resources directory in Mac OS X. Thus it allows you to put a data directory next to your exe on Windows, like you usually have all of your data in the Resources directory of the app on Mac OS X. And for both, you'll ask to open the image "data/something.png" for example.

Now.. why would one wish to read/write next to the app... in my opinion it's not a good idea. Especially because you don't know where the user put the app (thus you don't know whether you can write), and well.. I can't see any reason why you'd need to read next to the app. Because I suppose that would be some data for the app, and that should always be in the Resources directory or in some other specific directory of the OS. And if it's a user document, then you have to ask him where it is, like in any document-based application.

Besides, with SFML 1, I've never ever seen someone needing to read/write next to the app. "Probably" because of these reasons.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 05, 2011, 01:51:59 pm
Sorry, I'm not convinced (yet).

Quote from: "Ceylo"
The Resources directory should be the working directory because the equivalent to the data directory next to the Windows executable IS the Resources directory in Mac OS X.
If some OS(es) have a poor design we might not want to copy it – or, in this case, behave likewise – but let the user have the choice event if it means the user can make a bad choice. IMO, forcing the user to use/do/... something is bad.

Quote from: "Ceylo"
Thus it allows you to put a data directory next to your exe on Windows, like you usually have all of your data in the Resources directory of the app on Mac OS X. And for both, you'll ask to open the image "data/something.png" for example.
No offence, but this is kind of a poor app design : it's clearly more powerful to use abstraction here (e.g. have a 'give_me_my_wonderful_resources_directory_path' function). More generally, if you have any resources path it's way more convenient to update the path only in one place when you move the resources (e.g. you create a new subdirectory).

Quote from: "Ceylo"
Now.. why would one wish to read/write next to the app... in my opinion it's not a good idea.
So we shouldn't use the app working dir on Windows to store our data. Thus we won't use it on OS X too. Hence we don't need this feature.

I'm teasing a little bit but this is quite an interesting topic so don't hesitate to push me around too. :wink:
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 05, 2011, 02:13:57 pm
Quote from: "Hiura"
Sorry, I'm not convinced (yet).

Quote from: "Ceylo"
The Resources directory should be the working directory because the equivalent to the data directory next to the Windows executable IS the Resources directory in Mac OS X.
If some OS(es) have a poor design we might not want to copy it – or, in this case, behave likewise – but let the user have the choice event if it means the user can make a bad choice. IMO, forcing the user to use/do/... something is bad.

The user is not forced. He can still do chdir("../../.."), which is quite easier than finding the full path of the application, and adding "name.app/Contents/Resources".

Quote from: "Hiura"
No offence, but this is kind of a poor app design : it's clearly more powerful to use abstraction here (e.g. have a 'give_me_my_wonderful_resources_directory_path' function). More generally, if you have any resources path it's way more convenient to update the path only in one place when you move the resources (e.g. you create a new subdirectory).

I'm not sure I perfectly understand but.. what prevents you from setting your "wonderful resources directory path" as working directory, whatever you decide to do with SFML? What I mean is that in most cases the Resources directory is the best place to put your data, and that's why it should be the default working directory for SFML apps. This, however, does not prevent you from using another working directory for your app.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 05, 2011, 02:48:53 pm
Quote from: "Ceylo"
The user is not forced. He can still do chdir("../../.."), which is quite easier than finding the full path of the application, and adding "name.app/Contents/Resources".
It still looks hacky... in both ways (SFML change or user change).

I think we are mixing up the meaning of 'working directory'. Are we working in our resources directory or elsewhere ? Must we work in our resources directory or not ? I think that's two separate thing and we shouldn't change this. But still – I might be wrong.

I'm not looking for the most easy thing for the user but for the most logical. And on that point I'm still not sure what is the most logical.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 05, 2011, 02:58:31 pm
Quote from: "Hiura"
I'm not looking for the most easy thing for the user but for the most logical. And on that point I'm still not sure what is the most logical.

Uh.. okay. I was rather thinking with usability in mind.


Thus.. I can't say whether the Resources directory is the one you should "work" in, but it's definitely the one where you should "read" your app resources (with the reasons I gave earlier).
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 05, 2011, 08:05:40 pm
Oh sorry!  I didn't mean to start a war here! :-)

I just looked at the 1.6 code and I found where it checks for the resources directory.  

Now, let me add a few thoughts.  Application bundles are the standard way of building apps in OS X.  In a Mac OS X bundle, the resources directory is where all the assets exist.  Now, I don't think it is bad/good design, but a different design; it's just different from your typical Windows, Linux, etc application.

Now my opinion...  I would have to agree with Ceylo here and let me tell you why.  SFML is supposed to be a cross platform library.  The library itself should handle all the idiosyncrasies of the various platforms.  For instance, as a user of SFML and if I were to write code for say Windows and Mac OS X, I would have to do this now:

#IF WIN32
Image.LoadFromFile("image.png");
#ELSE IF OSX
Image.LoadFromFile(GetResourcesDirectory() + "image.png");
#ENDIF

Basically you get the idea.  The user of the cross platform library would need to differentiate which system he/she is using.  Using the 1.6 method, Image.LoadFromFile("image.png") would work across any system and it wouldn't matter as the same C++ code would work.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 05, 2011, 08:13:48 pm
What about a compromise where we instead of changing the working directory, we append the "application.app/Contents/Resources" to the path when loading assets if the application is a Mac OS X bundle?
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 05, 2011, 08:21:22 pm
Here I am adding fuel to the flame war.  Haha :-)

Anyways, I just wanted to add one more thing.  I checked the SDL library to see how they handle Mac OS X bundles, they essentially check to see if the application is a bundle, if not then fall back on the working directory.

Let me copy and paste the code here:


Code: [Select]

#ifdef __APPLE__
#import <Foundation/Foundation.h>

#include "SDL_rwopsbundlesupport.h"

/* For proper OS X applications, the resources are contained inside the application bundle.
 So the strategy is to first check the application bundle for the file, then fallback to the current working directory.
 Note: One additional corner-case is if the resource is in a framework's resource bundle instead of the app.
 We might want to use bundle identifiers, e.g. org.libsdl.sdl to get the bundle for the framework,
 but we would somehow need to know what the bundle identifiers we need to search are.
 Also, note the bundle layouts are different for iPhone and Mac.
*/
FILE* SDL_OpenFPFromBundleOrFallback(const char *file, const char *mode)
{
    FILE* fp = NULL;

// If the file mode is writable, skip all the bundle stuff because generally the bundle is read-only.
if(strcmp("r", mode) && strcmp("rb", mode))
{
return fopen(file, mode);
}

NSAutoreleasePool* autorelease_pool = [[NSAutoreleasePool alloc] init];


NSFileManager* file_manager = [NSFileManager defaultManager];
NSString* resource_path = [[NSBundle mainBundle] resourcePath];

NSString* ns_string_file_component = [file_manager stringWithFileSystemRepresentation:file length:strlen(file)];

NSString* full_path_with_file_to_try = [resource_path stringByAppendingPathComponent:ns_string_file_component];
if([file_manager fileExistsAtPath:full_path_with_file_to_try])
{
fp = fopen([full_path_with_file_to_try fileSystemRepresentation], mode);
}
else
{
fp = fopen(file, mode);
}

[autorelease_pool drain];

return fp;
}
#endif
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 05, 2011, 10:40:11 pm
Quote from: "zenkimoto"
Oh sorry!  I didn't mean to start a war here! :-)
No, don't be sorry! It's very good in fact : I'd like to make the better port as I can so if you help me with idea I'm happy.

Quote from: "zenkimoto"
What about a compromise where we instead of changing the working directory, we append the "application.app/Contents/Resources" to the path when loading assets if the application is a Mac OS X bundle?
This cannot be done in SFML the same way it is done in SDL (it would mean I have to modify Image, Sound, Music, ...).

Quote
#IF WIN32
Image.LoadFromFile("image.png");
#ELSE IF OSX
Image.LoadFromFile(GetResourcesDirectory() + "image.png");
#ENDIF
I agree : it would be shorter for the user. Notice I said 'shorter' and not 'easier' as it is not very complicated at all (just copy/past the code above). But the problem persists with Unix : a "good" application will be installed in /usr subdirectories (bin/share/... I don't know exactly), won't it ?
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 05, 2011, 10:53:03 pm
Quote from: "zenkimoto"
What about a compromise where we instead of changing the working directory, we append the "application.app/Contents/Resources" to the path when loading assets if the application is a Mac OS X bundle?

To me this doesn't really change the issue. You shouldn't have to change anything in order to build your app for both Windows and Mac OS X. And in both case, you should be able to use the default repository for each OS, not something specific to SFML.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 06, 2011, 03:03:40 am
Darn, I wasn't thinking... I thought the working directory wasn't supposed to change when I mentioned that compromise.  I can see how it really isn't.

Ah well, I guess it's up to Hiura.  :-)  For the time being, I'll just check for the resources directory.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 06, 2011, 03:12:48 am
Quote

I agree : it would be shorter for the user. Notice I said 'shorter' and not 'easier' as it is not very complicated at all (just copy/past the code above). But the problem persists with Unix : a "good" application will be installed in /usr subdirectories (bin/share/... I don't know exactly), won't it ?


I see what you mean.  True, it's not complicated.  I guess it just means that the user of SFML would need to be conscious of which platform they are using.  But doesn't that defeat the purpose of a cross platform library?  I would think that you would want the same code base working for all platforms. For example, if I wrote some sample code for you and my system was Windows.  You, say having an OS X system, couldn't just take the code and compile it.  You would need to modify the code in order to make it run.

I also think you're thinking in terms of UNIX.  For most OS X applications, users do not install anything in /usr/share, etc.  I usually am wary of applications that come with an installer rather than a bundle.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 06, 2011, 09:59:35 am
Quote from: "zenkimoto"
I see what you mean.  True, it's not complicated.  I guess it just means that the user of SFML would need to be conscious of which platform they are using.
We can put a big shiny warning in the tutorial and documentation. Yes, that would be great.

Quote
But doesn't that defeat the purpose of a cross platform library?
It depends : is it a high or low library ? Here, with SFML, we are in the second case so it might be subtle to know – and honestly I don't know; that's why I like this discussion.

Quote
I would think that you would want the same code base working for all platforms. For example, if I wrote some sample code for you and my system was Windows.  You, say having an OS X system, couldn't just take the code and compile it.  You would need to modify the code in order to make it run.
There's two aspect here : compilable and runnable. The first one is always true with SFML but no the second. Now these two are so close that we have to define with Laurent where SFML stops.

Quote
I also think you're thinking in terms of UNIX.  For most OS X applications, users do not install anything in /usr/share, etc.  I usually am wary of applications that come with an installer rather than a bundle.
I was in fact saying that you also need a function to get the resources path on Unix.
So you would have
Code: [Select]

string GetResourcesPath() {
#if defined ( SFML_OSX )
  return ...
#elif defined ( SFML_LINUX )
  return ...
#elif defined ( SFML_WINDOWS )
  return "";
#else
  #error Unknown OS
#endif
}

:
:
 
sf::Image img(GetResourcesPath() + "tagada.png");
Only on Windows you return nothing (i.e. ""). So should I do noting or should the SFML on Linux and OS X acts like on Windows ? (no rhetoric)

Or is it the job of an external library (maybe I can improve cpt (http://goo.gl/30wWy) with your help) ?
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 06, 2011, 01:09:13 pm
Quote from: "Hiura"
]We can put a big shiny warning in the tutorial and documentation. Yes, that would be great.

I don't really understand why you don't like the way SFML 1 works for this issue. And as I already said, users shouldn't have to care about that kind of issue. SFML should just do the job so that users can use the default resources directory for their OS, and nothing more.

Quote from: "Hiura"
I was in fact saying that you also need a function to get the resources path on Unix.
So you would have [...]

Maybe the Linux port should also use the default Linux directory for resources and set it as working directory. It's up to Laurent. But having to handle each OS differently (from the user's point of view) in a cross platform library is one of the worst thing to do (imho).
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 06, 2011, 03:45:32 pm
Quote from: "Ceylo"
I don't really understand why you don't like the way SFML 1 works for this issue. And as I already said, users shouldn't have to care about that kind of issue. SFML should just do the job so that users can use the default resources directory for their OS, and nothing more.
My main concern is that 'working directory' is not 'resources directory'; thus changing the current working directory to load one's data is not the right way to do, imo : it looks more like an hack than anything else.

Quote from: "Ceylo"
Maybe the Linux port should also use the default Linux directory for resources and set it as working directory. It's up to Laurent.
Yes absolutely, it's up to him. I'll follow the behaviour of Linux if Laurent updates it.  :wink:

But the thing is that SFML is low level and this feature is at a quite high level. And I don't want to go too far from Laurent's concepts about SFML.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 06, 2011, 03:52:10 pm
Quote from: "Hiura"
My main concern is that 'working directory' is not 'resources directory'; thus changing the current working directory to load one's data is not the right way to do, imo : it looks more like an hack than anything else.

What other meaning would you give to the working directory?

Quote from: "Hiura"
Yes absolutely, it's up to him. I'll follow the behaviour of Linux if Laurent updates it.  :wink:

But the thing is that SFML is low level and this feature is at a quite high level. And I don't want to go too far from Laurent's concepts about SFML.

Lauuuurent! We need you :D .
Title: SFML 2.0 Mac OSX in App Bundle
Post by: zenkimoto on March 06, 2011, 03:57:45 pm
Quote
It depends : is it a high or low library ?


SFML's competing library SDL checks for the Application Bundle.  So does that mean that SDL is a higher level than SFML?   I still feel that being a cross platform library you should hide the fact that it's cross platform to the user of the library.  I should have a single code base that can compile various platforms.


Quote
I was in fact saying that you also need a function to get the resources path on Unix.
So you would have [...]


I still have to agree with Ceylo.  I, as a user of SFML, would not want to see that.  


Quote
There's two aspect here : compilable and runnable. The first one is always true with SFML but no the second. Now these two are so close that we have to define with Laurent where SFML stops.


I think I'm starting to understand what you mean.  The resources path is kind of like a configuration issue.  I think other people like Laurent should chime in.

All in all, it's up to you guys as the developers of SFML to decide.  :-)
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Laurent on March 06, 2011, 04:35:25 pm
Quote
Lauuuurent! We need you

I don't think so :lol:
This is very specific to OS X, and honestly I can't help much. They do things so much differently than Linux and Windows...
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 06, 2011, 04:43:35 pm
Quote from: "Ceylo"
What other meaning would you give to the working directory?
In fact I don't give a strong meaning to the "working directory". It's too vague and can be easily change by anyone. Changing the directory for app bundle only doesn't resolve the potential problem for classic unix app. (I don't like this half solution, in some situations it works and in some other it doesn't.)

But I agree with you : having the working directory to something like the root is not very useful. I'm so-so with my solution and yours. Both don't feel right to me. :?
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Ceylo on March 06, 2011, 04:54:41 pm
Quote from: "Laurent"
I don't think so :lol:
This is very specific to OS X, and honestly I can't help much. They do things so much differently than Linux and Windows...

But what would you do for Linux?

Quote from: "Hiura"
But I agree with you : having the working directory to something like the root is not very useful. I'm so-so with my solution and yours. Both don't feel right to me. :?

With SFML 1, if the executable is a bundle application, the working directory is set to the Resources directory. If not it's set to the directory containing the executable.

In a classic unix app, the resources are never next to the app, but rather in /usr/share or something like that. But I don't really know much about these. Anyway, you could still set the default working directory for unix apps as the good one.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 06, 2011, 05:04:44 pm
Quote from: "Ceylo"
if the executable is a bundle application, the working directory is set to the Resources directory. If not it's set to the directory containing the executable.
I've nothing to say against the first part but I've to think a little bit about the second one. I'll come back here tomorrow with a fresh mind.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Laurent on March 06, 2011, 05:15:45 pm
Quote
But what would you do for Linux?

Nothing ;)
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on March 08, 2011, 08:11:28 pm
Here I am with news.

First, about classic unix binaries : I won't do anything with them – even if having the working directory set to the filesystem's root is kind of stupid. Why this choice ? Because you can easily get your binary path by using argv[0] argument of your main function.

Now about the bundle applications : I won't do anything too. I know this will upset you a little bit but I really think this is just not the right way to access your resources – an OS-specific function to get the resources path is more powerful IMO.

However, I've got (I hope!) one good news for you guys : I'll provide the GetResourceDirectory function with the Xcode Template in a separate source file automatically added to the project.  :wink:
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Canadadry on May 15, 2011, 05:35:35 pm
To just add my opinion, you must respect the guideline of the OS. On mac, all resources are in a specific folder, this folder is made for an easy access of resources. Not making it the working dir just break that without any gain. What we are discussing should transparent, that's why Apple made us a resources dir and a bundle for app. If your not convinced you should take a poll.

This is not an hack, this is what thing suppose to be on a mac. Easy to use, nothing more, nothing less.

However, your solution with the .mm file look like to an hack to me. Force user to have Cocoa and call to an obj-c++  should not be a solution. Neither than a conditional compilation, this add unwanted code for basic needs.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on May 15, 2011, 10:15:09 pm
Quote
o just add my opinion, you must respect the guideline of the OS.
Yes an no. I prefer to keep a very similar behaviour with SFML on Linux and Windows for "little" thing like this one.

Quote
On mac, all resources are in a specific folder, this folder is made for an easy access of resources.
Yes.

Quote
Not making it the working dir just break that without any gain.
No, because «working directory» and «resources directory» are two distinct concept and therefore there is no logical relation between the two. Moreover Apple doesn't seem to be a big fan of working directory from what I've seen : for example to access a resource you are encouraged to use NSBundle API (see this blog for an example (http://www.cimgf.com/2008/05/24/cocoa-tutorial-working-with-application-resources/)).

Quote
This is not an hack
Everything is an hack here : changing the working directory is an hack as having a "cross-platform" (yep, with a lot of define..) to get resource folder is an hack.

If you're developing on Windows or Linux you'd better having a function to get a "standard" (or not) resource directory. So should you on Mac, IMO. You should never rely on the current working directory to store stuff like resources.

I'm sorry if I look stubborn but until I'm not convinced (that is, you proved me that I'm wrong about the above points) I'm not changing this.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Kolja on June 18, 2011, 10:40:18 pm
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.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on June 19, 2011, 09:41:55 am
Quote from: "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:

Quote from: "Kolja"
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.  :)
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Kolja on June 19, 2011, 12:21:11 pm
Quote from: "Hiura"
Quote from: "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!

Quote from: "Hiura"

Quote from: "Kolja"
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 ;-)
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Hiura on June 19, 2011, 02:07:02 pm
Quote from: "Kolja"
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.
Title: SFML 2.0 Mac OSX in App Bundle
Post by: Kolja on June 19, 2011, 06:29:19 pm
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:
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. ;-)