Oolite Bulletins

This also applies to Oolite-Linux (and BSD and ...)

Is it worth my while getting rid of GNUstep GUI (and by consequence, the troublesome GNUstep Back)?

Benefits
- Removes a 3.7Mbyte dependency (probably make the download package 2MB smaller)
- Removes incomprehensible problems with GNUstep Back

What it'd need
- Our own NSColor and NSFont mini-implementation (and possibly a few other smaller things). They just need to be subsets of the full functionality - they aren't really used much

Part of it is selfish too - I would like to move my development machine from Fedora Core 2 to Fedora Core 5. Unfortunately, only GNUstep Foundation will even build on FC5 (short of a lot of gyrations with the configure script to convince it to compile without needing the static X11 libs, which are no longer shipped with FC). Copying my working FC2 installation of GNUstep to FC5 means the current tree compiles, but the GNUstep Backend refuses to initialize. I can get the game to run by commenting out:
in src/SDL/main.m (and the game runs fine with no apparent side effects, other than it no longer tries to initialize GNUstep Back - what problems did it originally cause in NSFont?)

If it will bring some benefits to the Windows build process too it might be worth doing.

Other things I might do - modify the dependency pack in Linux with a 'doctored' GNUstep base which disables the DTD warning too.

IIRC NSFont is only used to get the metrics of Helvetica or Arial. Storing these values would clearly be better for portability quite besides the dependency issue, although a move to FTGL would be preferable.

As far as I’m aware NSColor is only used to store RGB values, ignoring colour correction issues. As such, a simple RGBColor class could be knocked up in ten minutes.

NSFont - only used in [PlayerEntity starChartDump] - could almost certainly go

NSColor - used in LOTS of places but could easily be replaced with an OOColor wrapper, someone bright would have to write the colorWithCalibratedHue: saturation: brightness: alpha: routine if colour's going to be stored in its most useful form (as 4 GLfloats).

Okay - so I happened to have a copy of Foley - van Dam to hand...

r393

I've replaced most instances of NSColor with OOColor which implements only the methods that Oolite uses.

There are still instances of NSColor wherever GNUStep/Cocoa drawing needs to be done. These are in OpenGLSprite and [PlayerEntity starChartDump].

AFAIR GNUstep/SDL OOlite doesn't use any of the drawing code in OpenGLSprite, so it could all be ifdef'd away as long as the GNUstep version doesn't mind being without the star chart pictures.

I really need my own Foley et al. I keep borrowing it from the university library, but every few months some other bugger wants it.

I take it you’ve got the HSV conversion working. If not, it’s simple enough.

OK - so I've done the relevant #ifdefs and modified the makefile/postamble to now build without using GNUstep GUI at all (it now links with just gnustep base). There are still some outstanding things I need to fix

- some 'does not respond to...' warnings - probably code never reached under GNUstep
- nightly build does not work at all (strange problems with OOColor - probably the build environment on vexed3 - complains that OOColor does not respond to retain/release etc. and later dies with an error

The libgnustep-gui free build still puts everything in oolite.app or oolite.debug - but the executable is built with the style 'objc program' rather than 'application'. Hopefully I've got all the bits right in the Windows part of the makefile/postamble too!

Nightly build breaks fixed - due to AppKit still leaking in in places and causing bad stuff to happen. Hopefully I didn't break the Mac build in the process!

Edit: I broke the Mac build in the process. But I fixed it now...

Good one winston, I'm glad to see the back to gnustep-back and AppKit classes.