Author Topic: Native OSX application  (Read 5520 times)

0 Members and 1 Guest are viewing this topic.

Offline Bjarni

Native OSX application
« on: March 24, 2013, 12:53:52 AM »
Just as the title says. This diff turns the binary into a native OSX application.

Normally Xcode builds the application bundle for you and that is the way to do it if you ask Apple. However it's possible to make one with a shell script if you know how bundles work.

Usage instruction:
"make bundle" does everything for you.

Features:
  • Executes directly without opening terminal.
  • Proper icon.
  • Proper "get info" window in Finder.
  • Finder is aware of version number (autogenerated from simversion.h when building).
  • Sets working directory correctly even when started in a bundle without breaking how working dir is set when started from CLI (read: started like it is right now).

TODO:
  • OSX/simutrans.icns is missing. Somebody should make the icon image using "Icon Composer" (part of Xcode).
        It needs squared images of sizes 16, 32, 128, 256 and 512 pixels, though I think it's able to downscale nicely if needed. It's drag-n-drop once you have the source image(s) to make it from.
  • Dependencies for OSX/getversion is screwed. It recompiles every time. Luckily it compiles instantaneously.
  • OSX/plistgen.sh should get a proper copyright string. The one I added is basically a placeholder.
  • Some cleanup is needed. Mac specific code in common.mk doesn't seem right.
  • Text output is written in the console, which doesn't open automatically. The user will have to open /Applications/Utilities/Console manually if the game crashes. This is the standard on OSX, though a number of users is unaware of this. The console should be mentioned in the readme.

It should be noted that "make bundle" fails unless OSX/simutrans.icns is present. Either remove the line copying it in the makefile or add a placeholder (possibly one from another application). Unzip simutrans.icns.zip and place it in OSX.

This diff is based on rev 6390 (112.2) as I had problems with head revision crashing (without local modifications). I didn't look into those crashes though.

There is one potential benefit from using a bundle besides "appear like a native application". When the distributed binary is actually a directory, then it's possible to add more files inside. Stuff like fonts, text and stuff like that could be placed inside. This could turn upgrading into "drag-n-drop" a single "file". However you should think a bit if you do that. I have seen something where all the files were placed inside the bundle by a script. This included config files and readme and as a result the majority of users will never find it.

I almost feel bad for showing up all of a sudden and fixes such a long term issue in just two hours. I can imagine what poor Timothy must feel like. However I have to admit I relied heavily on the code OpenTTD uses to do this. I went through hell to write it once. Only an idiot would do it twice ;)
« Last Edit: March 25, 2013, 05:25:17 PM by Bjarni »

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 6
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Native OSX application
« Reply #1 on: March 24, 2013, 10:12:15 AM »
Nice work!

For icons, you should contact An_dz, he's the official icon artist ;)



Nice work!

For icons, you should contact An_dz, he's the official icon artist ;)

Mod note: please do not double-post. Edit your last comment instead.
~IgorEliezer *trollface* ;3
« Last Edit: March 25, 2013, 01:59:25 AM by IgorEliezer »

Offline Dwachs

  • DevTeam, Coder/patcher
  • Administrator
  • *
  • Posts: 4163
  • Total likes: 146
  • Helpful: 147
  • Languages: EN, DE, AT
Re: Native OSX application
« Reply #2 on: March 24, 2013, 01:42:11 PM »
Bjarni, thank you very much :)

Fabio: dont double-post, edit your last post instead  :police: lol
Parsley, sage, rosemary, and maggikraut.

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 6
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Native OSX application
« Reply #3 on: March 24, 2013, 05:16:28 PM »
Fabio: dont double-post, edit your last post instead  :police: lol
D@mn Android for that! sometimes I reply but my post apparently doesn't show...

Offline greenling

  • Lounger
  • *
  • Posts: 1729
  • Total likes: 2
  • Helpful: 15
  • Simutransarchology it my hobby!
  • Languages: DE,EN
Re: Native OSX application
« Reply #4 on: March 24, 2013, 05:28:22 PM »
Hallo Fabio
D@mn Android for that! sometimes I reply but my post apparently doesn't show...
I use no mobile Telephon to go in the Forum.
They make often problems to write a text.
Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • Total likes: 6
  • Helpful: 91
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Native OSX application
« Reply #5 on: March 24, 2013, 07:42:38 PM »
@greenling: indeed they do. But I rarely have the chance to visit the forum using a traditional pc/laptop, at last with my mobile I'm always up to date with what's going on.

Offline An_dz

  • Web Admin
  • Administrator
  • *
  • Posts: 2548
  • Total likes: 279
  • Helpful: 89
  • D'oh
    • by An_dz
  • Languages: PT, EN, (it, de)
Re: Native OSX application
« Reply #6 on: March 24, 2013, 07:54:48 PM »
Does it uses Quartz to render or still uses SDL?

D@mn Android for that! sometimes I reply but my post apparently doesn't show...
Where's the Ctrl+F5 when we need it? :D

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8698
  • Total likes: 300
  • Helpful: 228
  • Languages: De,EN,JP
Re: Native OSX application
« Reply #7 on: March 24, 2013, 10:58:47 PM »
Thank you very much, you contribution is highly appreciated. Even more, since we do not have a developer who own a mac and have to do crosscompiling. It seems this should work even on a crosscompiler.

Would it be possible to have the PowerPC binary in there too?

Sorry, a stupid question: Where goes now the simutrans stuff, into simutrans.app or into simutrans.app/simutrans ?
« Last Edit: March 24, 2013, 11:50:30 PM by prissi »

Offline Bjarni

Re: Native OSX application
« Reply #8 on: March 25, 2013, 06:24:25 PM »
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:
Code: [Select]
#!/bin/sh

"${0}.`uname -p`"

if [ "$?" != "0" ]
then
/usr/bin/osascript <<-EOF
    tell application "Console" to activate
EOF
fi
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 :P
« Last Edit: March 26, 2013, 12:54:03 AM by Bjarni »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8698
  • Total likes: 300
  • Helpful: 228
  • Languages: De,EN,JP
Re: Native OSX application
« Reply #9 on: March 25, 2013, 11:17:54 PM »
Please email the icon to me. I did a try with an automated web icon converter, but I am sure it will be ugly.

Could you please test the bundle I did using the nightlies (as I do not have a crosscompiler here). Please find them at http://www.physik.tu-berlin.de/~prissi/simutrans/simumac.zip

Offline Bjarni

Re: Native OSX application
« Reply #10 on: March 26, 2013, 12:51:52 AM »
It works after I modified a few things.

  • The second argument to plistgen.sh was "simutrans.sh" meaning it looked for simutrans.sh.icns and so on. I removed a bunch of .sh from the plist.
  • Contents/MacOS/simutrans.sh also needed to have .sh removed or it would look for simutrans.sh.i386.
  • Contents/MacOS/simutrans is corrupted. I copied the code from my previous post to fix this.
        The console opened with each crash after this replacement. Looks like this part works flawlessly :)
  • The change to simmain.cc from the diff isn't included. It started searching for pak files and stuff in Contents/MacOS. I copied it there to compensate for this test.
  • dyld: Library not loaded: @executable_path/../Frameworks/SDL.framework/Versions/A/SDL
    This one is interesting. It searches for SDL in Contents/Frameworks. I copied it there and it works.
    I should add that I never installed this framework in my system as I have SDL in unix style (installed with macports) and I fear having both can cause problems. Besides simutrans works just fine with unix style when it's compiled with it.

The icon isn't that bad, but I sure know which one i like best. It does show the icon correctly after editing the plist, which I guess is the main issue here.

The SDL location thing is interesting. It means it's possible with little or no work to include SDL in the distribution and the end user will not have to worry at all. The problem is that nothing is really simple though. There is two SDL frameworks for OSX, one for x86 and one for PPC. Sure we could modify the ppc one to look for SDL-ppc.framework, but bad luck hit us: OSX 10.4 for intel also uses the ppc one (don't ask me why). That complicates stuff quite a lot as it would either need two x86 binaries or one which looks for a framework based on OS version at runtime. I have written runtime checks for OSX version in C++ before and it shouldn't be impossible.

Alternatively MacOS/simutrans could come in handy. It could do something like using an applescript to tell safari to open the SDL download page if SDL is missing or move the right framework into position based on runtime OS, possibly with an alias. There are some options to look into here.
« Last Edit: March 26, 2013, 01:07:39 AM by Bjarni »

Offline Bjarni

Re: Native OSX application
« Reply #11 on: March 26, 2013, 07:07:45 PM »
**** you guys. You should have said something. Now I have to double post as I have something major new to say  ::-\

I made a new diff based on feedback here. Now it supports crosscompilation as well as being able to make a bundle with binaries for both ppc and x86.
Also a new major breakthrough: the bundle contains the sdl framework for both cpu types and makes a symbolic link to the right one when starting. People should be able to just download this bundle and then double click to start the game without messing with libraries.

I added a new target "make bundle_dist" to make the bundle, which works everywhere. Make bundle is mostly unchanged and is still the way to go if somebody wants to compile their own bundle and use it on their own computer.

Some variables need to be set for bundle_dist to work and I made a list of those in OSX/osx.mk with descriptions to what they should contain. Those settings are only needed when adding both binaries to a bundle.

I think all major issues should be solved by now. It still has something minor like getversion recompiling every time a bundle is made, but nothing big.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 8698
  • Total likes: 300
  • Helpful: 228
  • Languages: De,EN,JP
Re: Native OSX application
« Reply #12 on: March 26, 2013, 09:50:38 PM »
Thank you very much. I will need to tweak it, as is seems to be run only on a mac. Since I do not have a crosscompiler, I rely exclusively on the nightly compiler, which runs on a custom made Linux gentoo. As such the bundle building and the compilation might be done on two different computers, with the SDL just downloaded.

I am a little confused, as there seems to be only a single SDL version to download, i.e. how to build a proper framework link on my msys. 7z can extract dmg, so that is not the problem.

EDIT: WHat does "${0%/*}"? I get bad substitution under my shell. So I am confused to where I have to put the SDL then?
« Last Edit: March 26, 2013, 09:57:02 PM by prissi »

Offline Ashley

Re: Native OSX application
« Reply #13 on: March 26, 2013, 11:54:39 PM »
I almost feel bad for showing up all of a sudden and fixes such a long term issue in just two hours. I can imagine what poor Timothy must feel like. However I have to admit I relied heavily on the code OpenTTD uses to do this. I went through hell to write it once. Only an idiot would do it twice ;)

This is a reasonable stop-gap measure I suppose...
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

Offline Bjarni

Re: Native OSX application
« Reply #14 on: March 27, 2013, 12:18:38 AM »
Thank you very much. I will need to tweak it, as is seems to be run only on a mac.
binary_picker.sh is designed to be executed on mac (it even contains an applescript ;)). "make bundle_dist" is designed to work for crosscompilers.

The whole idea is to do it like this:
-compile a ppc binary
-set BINARY_PPC to that binary
-set SDL_PPC to the sdl framework used for the ppc binary
-set CXXHOST to CXX for host system (gentoo)
-run make bundle_dist when compiling the x86 binary and it will do everything for you.

If that needs tweaking to work on a non-mac, then I would like to hear what went wrong.

there seems to be only a single SDL version to download
http://www.libsdl.org/download-1.2.php contains two frameworks for mac.

EDIT: WHat does "${0%/*}"? I get bad substitution under my shell. So I am confused to where I have to put the SDL then?
$0 is the script being executed. The bundle does that with an absolute path, though ./simutrans would likely be the one you see if you start it yourself from terminal.
% means removing from the rear. In this case it removes the last / and everything after that.
It gives the path to MacOS. I then add "/../Frameworks" meaning it ends up containing "*.app/Contents/MacOS/../Frameworks"

However it would be easier to find SDL location based on OSX/osx.mk line 40 and 41. This is where the makefile places the sdl frameworks.

Offline acki

Re: Native OSX application
« Reply #15 on: August 11, 2013, 01:05:53 PM »
Hi,

I might have a really stupid question: how do I make this work?
I'm actually new to Mac; I switched from PC recently and have been very disappointed with the Mac version of Simutrans...

Thanks

Offline acki

Re: Native OSX application
« Reply #16 on: August 11, 2013, 01:06:12 PM »

Hi,


I might have a really stupid question: how do I make this work?
I'm actually new to Mac; I switched from PC recently and have been very disappointed with the Mac version of Simutrans...


Thanks

Offline kierongreen

Re: Native OSX application
« Reply #17 on: August 11, 2013, 01:14:07 PM »
What are you disappointed with?

Offline acki

Re: Native OSX application
« Reply #18 on: August 11, 2013, 01:15:37 PM »
What are you disappointed with?
Oh just the performance of the regular Simutrans for OSX... very slow. So I'm happy to find info on a native OSX app; just wondering how to make this work...

Offline Bjarni

Re: Native OSX application
« Reply #19 on: August 11, 2013, 01:19:29 PM »
I agree that it is horribly slow on mac. That's why there is an interest in a version without SDL. However it's still somewhat unplayable and pretty idle at the moment as you can read here: http://forum.simutrans.com/index.php?topic=8783.0

The best advice I can give at the moment is to reduce the window size.

Offline kierongreen

Re: Native OSX application
« Reply #20 on: August 11, 2013, 01:35:43 PM »
Ah the speed issue... Is there still the option of running Windows versions emulated which are faster?

Help getting the Mac version working well is always appreciated - the main developers don't tend to use Macs so it is difficult for us to test performance. If you can help in any way with that feel free :)

Offline meme

Re: Native OSX application
« Reply #21 on: August 25, 2013, 10:09:57 AM »
I run simutrans in OS X wine :( - And it is ~ 2-4 times faster, sometimes more.. - If there's something I can help with, I'll..
« Last Edit: August 25, 2013, 10:23:12 AM by meme »


Offline Bjarni

Re: Native OSX application
« Reply #22 on: August 25, 2013, 11:03:52 AM »
I run simutrans in OS X wine :( - And it is ~ 2-4 times faster, sometimes more.. - If there's something I can help with, I'll..
If you know how to code, then you could look at the thread I linked to about a native GUI for mac. That would likely be the best (only?) option.