SFML 2.0 Mac OSX in App Bundle

[zenkimoto]

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.

[zenkimoto]

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.

[Hiura]

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.

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.

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.

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 with your help) ?

[Ceylo]

]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.

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).

[Hiura]

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.

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.

[Ceylo]

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?

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 .

[zenkimoto]

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.

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.  

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.  :-)

[Laurent]

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...

[Hiura]

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. :?

[Ceylo]

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?

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.

[Hiura]

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.

[Laurent]

But what would you do for Linux?

Nothing

[Hiura]

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:

[Canadadry]

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.

[Hiura]

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.

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

Yes.

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).

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.