I made an icon thanks to An_dz help (which was linking to the official one). I lightly modified it to provide a somewhat transparent white background for the text as it has to work with a black background. See the example screenshots. It's only 508 pixels wide and I should have used 512, though I don't think anybody will notice the difference.
It's 140k zipped though (164k unzipped), which means it fails the 64k limit for the forum. I'm not sure where to upload it, but I'm sure you will tell me
It seems this should work even on a crosscompiler.
There is one issue. Currently getversion is compiled for target system, but it is only used when generating the plist on the host system. This should easily be fixable and it's the only issue.
Would it be possible to have the PowerPC binary in there too?
The official approach would be to make a "universal binary". This can be done with compiler flags (not possible with crosscompilers) or using the application "lipo" to merge the two files.
However I don't feel like digging up the source to compile for a new system so I came up with a plan B, which is kind of a hack though. The bundle will execute the file "simutrans" (or whatever plist tells it). Nobody said it have to be a binary. I came up with this shell script:
if [ "$?" != "0" ]
tell application "Console" to activate
This wil execute simutrans.i386 or simutrans.ppc depending on what uname returns. I haven' tested it on PPC (yet?) but it should work.
Only the first two lines are really needed. However I added a check for exit status. If it crashed, then it invokes osascript, which invokes an applescript, which opens the console. It doesn't look pretty, but at least it actually shows why it crashed without having the user to manually open some other application.
I would argue that "Error: Cannot open 'font/prop.fnt'" shouldn't cause a segmentation fault, but that's another story. It does causes OSX to open a window with "application crashed, report to Apple?", which really isn't what we want for that kind of error.
Sorry, a stupid question: Where goes now the simutrans stuff, into simutrans.app or into simutrans.app/simutrans ?
It's not stupid. Bundle anatomy isn't really well known, not even to mac users.
Think of .app like .exe. It's an executable file which is placed next to the files it assumes is placed next to it. It is supposed to behave just like the binary itself regarding simutrans files.
The inside of the bundle is only meant for files not touched by most users. Say if we want the text directory to be invisible and automatically updated when the user downloads the newest version, then it can be moved to simutrans.app/Contents/Resources/text. This will eliminate user failure to keep .tab files in sync with the binary version. Somebody with a good understanding of what each files does could consider such options. However currently the game expects all those files to be in the same directory as the .app dir.
Personally I would recommend adding unix style SDL libs to the bundle. It would honour SDL license agreement as it would be separate files while at the same time the end user will not have to consider installing 3rd party libraries to just play the game.
While this is still true, using the SDL framework in the bundle appears to be the easy approach for now as it is already looking for the framework in the bundle.
Also it's a good idea not to rely on simutrans.app to be named that. Eventually somebody will bug report "simutrans .app" fails to execute as .app is hidden, which hides the space as well. I specifically made the diff to not care for that name. The names for subdirs in .app is fixed though.
at last with my mobile I'm always up to date with what's going on.
This says the guy who double posted because he looked on a cached outdated page