No worries, I don't expect you to read Apple developer documentation. I know you're stepping back a bit, and that's fine. It's just helpful to have another set of eyes saying 'yeah that seems sane' or 'WTF!?'. I'm actually surprised that others haven't chimed in more.
The issues with the 1.5 packaging are ones that stem from wanting the presentation of the disk image to look a certain way, more than doing it the right way. In retrospect this was a very bad thing... A few things I can say are this though... The big issue was that the wrapper files that launched the installer were legacy "PowerPC PEF executables", a very old, flat (e.g. not an application 'bundle'), extensionless executable format. Rosetta (the ppc emulation for Mac on x86) could handle these I believe, though there may have been some issues with an older, quickly deprecating framework called Carbon as well. With Lion, (10.7), the Rosetta compatibility layer is gone, you can't even install it... I would have never expected Apple to dump Rosetta so soon. Clearly the packaging is, for lack of a better term, completely fucked to hell.
In any case, I have plans to make that better. It won't be too hard.
So yeah, back to the topic. This link seems to show that I will have a reliable working path. This would be in the folder containing the bundle. I whipped up a quick test with Xcode and this seems like the case (data folder in Neverball.app/Contents/Resources). I launched it various different ways, and it was successful every time. I used the Dock, double-clicking it, and running launch commands from the command line:
$ open /...../trunk/macosx/xcode/build/Devel/Neverball.app/Contents/MacOS/Neverball
$ open /...../trunk/macosx/xcode/build/Devel/Neverball.app
The one issue I can see with this, which could be a blocker, is that the path becomes:
and similar for Neverputt. If you happened to rename the application bundle to "Neverball2.app" or something, it would no longer be able to find the data folder. This config would only be set for release versions so I don't know that it matters. I'm not aware of people renaming applications very often outside of testing. If this is a blocker, than I think I could easily do something similar to the instructions at the link I listed above.
The non-breaking solution to the case above would be to get the directory INSIDE the application bundle: "Neverball.app/.", OR next to the executable: "Neverball.app/Contents/MacOS/.", so that renaming doesn't break anything. At this level we can be reasonably assured that folder renaming won't happen, and even more, folder renaming inside the bundle usually breaks stuff anyways.
I would suggest that we do use symlinks though, as the location of the data folder may indeed differ. Either: "/Library/Application Support/Neverball/data" or "~/Library/Application Support/Neverball/data". The installer can handle setting up the correct symlink based on a user (~/Applications/) or system (/Applications) install. (Does that seem reasonable? If not, I can try to brainstorm a better way... Also going to look at some docs now.)
Whew, that's a long post.
EDIT: The more I think about it, the more I think I should go with the latter "non-breaking" solution... What's your advice on editing SDLMain.m to our needs? Obviously it's pretty trivial for me do to (very different from what's at that link though). But my point is: should we keep SDLMain.m and SDLMain.h in the repo then? How do we deal with customizations of things we rely on?
Mac OS X Xcode project & package maintainer.
If you have some Neverball related files you need hosted somewhere, please send a me forum PM/email.