[Wesnoth-dev] Re: Static Build on Mac OS X

[Fairydreams (General)]

Just a little history which may clarify things...

The MacOS X version was started around v.0.4 of Wesnoth. The idea  
behind it was to keep a pure copy of Wesnoth but as a well behaved  
Mac application. It started off with data in the usual Unix places.  
This is not how a well behaved Mac application works, hence the data  
was moved. This should be kept for as long as the target audience are  
Mac users rather than Mac developers. Moving to Unix locations will  
only cause problems. My view is that if someone is capable enough to  
design a decent scenario then they can work out how to reveal a  
folder using a single menu choice.

As for editors, originally I was urging for the editor to be part of  
the core Wesnoth. At one point there was a Python build of this. When  
I queried about the editor not being suitable for MacOSX I was told  
that the tools were not part of core Wesnoth and so cross-platform  
compatibility was not required. Hence in order to allow Mac users  
access to design tools I built the Cocoa editor. This editor can be  
standalone or integrated. An external editor can still access all  
files within a bundle, after all a bundle is still a folder.

Getting Wesnoth to work properly on MacOS X has always required quite  
a few changes. Mostly I tried to accomplish this outside of the code  
code (to reduce #ifdef __APPLE__ ) and so used compiler options and  
the Cocoa wrapper. Each new version has provided its own headaches  
and this version is no different. The editor was in even worse shape  
for the Mac and broke so often that I considered it easier to write a  
new version in Cocoa than keep the standard one running. As it was  
not core Wesnoth that seemed logical.

Some of the extra functionally added in the MacOS X version is to  
make it a well behaved Mac application. In other words, the user  
might well think it broken if it does not do things. I would not  
consider this a fork in the code as wherever possible effort has been  
made to make the core Wesnoth code has as few #ifdef __APPLE__ as  
possible. All it is porting to MacOS X.

As for the future, Wesnoth should always be buildable with XCode as  
that is the official development platform on the Mac. If it could be  
compiled by the command line too, then excellent.

Relying on Fink for developer tools is fine. There is no problem with  
them having to jump through extra hoops. Just be careful not to add  
extra Fink dependencies (i.e. on Fink versions of libraries used) as  
there could be a danger of building in Fink dependency in the final  
app which would be a disaster for MacOS X users.

Having a game identical in *gameplay* for all users is essential.

Having identical *core-code* is ideal.

Trying to make the *application* identical for all users is a  
retrograde step. Users have chosen their platform (Windows, Mac,  
Linux, etc). The game should be a well behaved application on each of  
these platforms. Mac users expect certain functionality. To remove it  
just because Linux users don't expect that is poor user-interface  
programming.

Personally I think the core issue is far less what we do with  
libraries, but far more how old a version of MacOS X we intend to  
support. There is a large amount of effort in supporting 10.2.8 and  
in some cases this can actually make the application more unstable.

I would like to say I'm sorry that I haven't been able to give this  
last version more time, but the day job is eating into my lunch  
breaks at the moment. Usually that has been my Wesnoth time :)