Maybe a better way to deal with this would be to detect the case that the engine gets launched from the GUI (rather than just blindly checking for the darwin case), if that's possible. But I'd say that for now this will do since that's just how the Mac version works right now.

However, I think that in that case the GUI shouldn't just ignore the engine cwd, as the code above does, but it should really force the engine to cwd to the GUI's working dir (i.e., user's HOME). Otherwise, in the GUI it looks like the program runs in HOME when the engine really runs somewhere entirely different (in app.nw) which can raise a lot of confusion. In particular, at present it's hard for the user to predict the directory where externals will run. Most externals will do the right thing and load files given as relative pathnames relative to the patch directory, but some don't (fluid~ for example takes filenames relative to the engine's cwd). Thus we should really make sure that the engine's cwd matches up with what the GUI pretends it to be.

I can prepare a merge request so that you see what I mean if I didn't explain it well enough.

Note that all this isn't an issue on Linux or Windows, where the user knows that the application, including the engine, runs in HOME when he launches it through the desktop icon, or in the shell's cwd when he launches it via the command line.

Reviewing the startup code, I found that gui_path wasn't determined properly and that the engine was actually launched in the app.nw dir. So I fixed the gui_path initialization and made sure that the engine gets launched in HOME if the GUI starts the engine. Also, the workaround in this commit isn't needed any more, so I removed it again. This fixes all issues on OSX for me, and the user now can have a reasonable idea where in the file system app and engine run on OSX which is consistent in behavior with the other platforms. Merge request is now up at !71 (merged).