On Sun, Apr 17, 2005 at 08:46:57PM -0500, Richard Kettering wrote: > The kicker is - he's the only one who CAN do the maintenance on this, > since he is the exclusive source of those files (someone else could of > course make their own version, essentially forking them, but that would > be silly).
Several people, including Sanna, Crimson Penguin and myself, have XCode project files to build BfW, forked off the common base of Sithrandel's XCode project file from a few releases ago. Currently these project files all refer to Sithrandel's additional Cocoa files, and therefore Sithrandel is really the right person to maintain this file. However, we could also consider an XCode project file to build BfW as a commandline app without the Cocoa bits. It should be quite simple to create a new project file for this. This file would have to be maintained in parallel with the configure/Makefile system used for most platforms, similar to the way the VC++ project file is maintained by David. Instead of using XCode to maintain a set of code dependencies in parallel with the official configure/Makefile system, I've found it simpler to just use the standard commandline build, and to provide feedback when changes to the build process breaks the commandline build on Mac OS X. For instance, the requirement for a recent Freetype 2 broke my build, and I provided a simple workaround by defining the macros that were not present in older Freetype distributions (like the one that ships with Mac OS X 10.3). If we really want to support XCode, I think it would be possible to create a trivial XCode project file which just calls configure and make to do all the work. To better support Mac OS X, we thus need to choose between pure commandline (which already works fine), commandline-with-XCode-wrapper (would need to be created), XCode-emulating-configure-make (would need to be created) and XCode plus significant additions (as already maintained by several people). The real issue here is that Sithrandel's code adds a lot of bits and pieces onto the core distribution. Some of these are necessary for the application to be properly integrated in a Mac environment: for instance, by providing application icons, allowing the application to be launched from the Finder by double clicking it (something the vanilla commandline build does not support), and supporting commandline arguments in an app that is launched by double clicking. Some of Sithrandel's additions are interesting but probably unnecessary, like installing user campaigns by drag-and-dropping them onto the application. Some additions provide new functionality, such as the campaign editor. Finally, some additions provide alternative ways of doing things, like the build only supporting the map editor function in the campaign editor instead of the standard map editor. (Note that the map editor works fine as a commandline app on Mac OS X.) On the other hand, not even Sithrandel's build supports the Cmd-H shortcut to hide the application, or even Cmd-Q to quit, and these would be prerequisites if we want the application to conform to the Mac OS X interface guidelines. To summarise, we have some bits that should be added to the core codebase, like handling commandline arguments and launching from the Finder. We have bits that perhaps do not need to be (drag-and-drop and campaign editor), and which are written using the Mac-only Cocoa framework. Finally, we have bits that should be but which do not exist, like a proper map editor build (unless Sanna has managed to get this to work), and better support for the user interface guidelines. The first category should be integrated into the existing build process. Ideally we do need to build an application that behaves the way people expect Mac applications to behave, that is supports launching by double clicking an icon in the Finder. This requires some but not all of the code from Sithrandel's Cocoa files to be integrated into the project. The third category is pretty important also. I would prefer if the second category stays out of the core codebase, since it does not fit with the ethos of the rest of the project, which has cross platform support as a core value. Other than Sithrandel, we don't have any programmers who are familiar with the Mac OS X idiom, so any Mac OS X specific additions depend completely on Sithrandel. Sithrandel -- over to you. :-) -- [EMAIL PROTECTED]
