FOSDEM and beyond (next stable release of base)

[Richard Frith-Macdonald]

Firstly, huge thanks to Lars for organising everything and providing the 
impetus to get a GNUstep presence at FOSDEM this year.

Also, thanks to the Etoile people ... for the first time we had about as many 
attendees from Etiole as from GNUstep 'proper', and it's quite inspiring to see 
the ideas generated.

And we should also thank the FOSDEM organisers ... who provided use with the 
whole event, and who seem to get better at it each year.

We only had a room for the Sunday this year, but even so there is a clear 
pattern from the years I've been attending ... the morning sessions are largely 
unattended (mostly because of the beer drinking on the Friday and Saturday 
evenings), but the afternoons are packed (perhaps we should hire a fan or air 
conditioning unit to make it more pleasant).  Next year we should definitely 
keep formal presentations for the afternoon and keep the mornings for 
discussions where people with particular issues can come and ask for help from 
someone who knows more (or just talk to someone else for a fresh viewpoint).

I'm not going to go into details about the presentations as I expect they will 
be available on the wiki, but I will say that one of the more important talks 
for me was Fred's discussion on making a 1.0 release of gnustep-gui which, 
along with a few other discussions, crystallized thoughts I've been having 
about the base library.

For what it's worth ...

I'd make a gui release compatible with (ie implementing all of) an older 
version of AppKit (probably OSX 10.2).
I'd not consider the state of the theme engine a show-stopper ... it's an extra 
API and can be marked as unstable while still having the AppKit  API be stable.
I'd add an unused pointer ivar to all public classes, so that we can alter the 
internal implementation of those classes without breaking ABI


That's pretty much what I want to do with gnustep-base:

Make a new 'stable' release (this year!) formally declared as OSX10.4 
compatible ... possibly to be versioned as gnustep-base-10.4 for marketing 
purposes.
I've been hesitating for ages because we don't have the OSX applescript support 
classes, and I just hate them and don't want to write them (as we already have 
loads of scripting options available), but David Chisnall (who has just had a 
book on Cocoa programming published) told me that Cocoa developers don't use 
the applescripting stuff because they don't like it any more than I do ... so I 
no longer consider this a show-stopper.
We will need a big disclaimer, that where Apple changed class/method behavior 
between OS versions, we do not guarantee to use the 10.4 behavior but may 
actually have implementation details compatible with a more recent OSX.
In this release, add an unused pointer variable to many classes to allow for 
rewrites without breaking ABI.
In this release, restructure code to move extensions into the additions library.
In this release, move to compatibility with the Apple objc runtime as much as 
possible.
I've created a new branch in subversion (named 'reorg') to do the 
reorganisation in.

Specific reorganisations I anticipate:

Move all our additional methods into separate files for each class using the 
naming convention classname+categoryname.[hm]  which seems to have become the 
most commonly recognised way of naming category source files.
Put them all in the 'additions' library (automatically part of the base library 
on Cocoa systems)
Move any classes which Apple had deleted from OSX10.4 into the additions 
library.
Have a 'GNUstepBase/Additions.h' header (like Foundation/Foundation.h) to pull 
together all the extensions so we can easily change code to include it, or 
leave it out when compiling in strict OSX compatibility mode.
Rewrite GSObjCRuntime.h to change most of the definitions to match the *new* 
runtime rather than having macros and function with a GS prefix to wrap them.
Checking to find any missing functionality (other than the apple scripting 
classes) and implement it.
Make sure the additions library builds on OSX and can be used simply by 
including GNUstepBase/Additions.h, to make it really easy to port code.

Volunteers requested!

Comments welcome ...  consider the above a fairly firm roadmap, but not 
immutable