Getting rid of GNUstep GUI

News and discussion of the PC port of Oolite.

Moderators: winston, another_commander

Post Reply
User avatar
winston
Pirate
Pirate
Posts: 731
Joined: Mon Sep 27, 2004 10:21 pm
Location: Port St. Mary, Isle of Man
Contact:

Getting rid of GNUstep GUI

Post by winston »

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:

Code: Select all

        // This is still necessary for NSFont calls.
	[NSApplication sharedApplication];
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.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

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.
User avatar
aegidian
Master and Commander
Master and Commander
Posts: 1161
Joined: Thu May 20, 2004 10:46 pm
Location: London UK
Contact:

Post by aegidian »

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).
"The planet Rear is scourged by well-intentioned OXZs."

Oolite models and gear? click here!
User avatar
aegidian
Master and Commander
Master and Commander
Posts: 1161
Joined: Thu May 20, 2004 10:46 pm
Location: London UK
Contact:

Post by aegidian »

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.
"The planet Rear is scourged by well-intentioned OXZs."

Oolite models and gear? click here!
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

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.
User avatar
winston
Pirate
Pirate
Posts: 731
Joined: Mon Sep 27, 2004 10:21 pm
Location: Port St. Mary, Isle of Man
Contact:

Post by winston »

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!
User avatar
winston
Pirate
Pirate
Posts: 731
Joined: Mon Sep 27, 2004 10:21 pm
Location: Port St. Mary, Isle of Man
Contact:

Post by winston »

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...
dajt
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 364
Joined: Tue Aug 17, 2004 7:05 am
Location: Orange, NSW, Australia

Post by dajt »

Good one winston, I'm glad to see the back to gnustep-back and AppKit classes.
Regards,
David Taylor.
Post Reply