Re: FOSDEM and beyond (next stable release of base)

[Quentin Mathé]

Hi Richard,

Le 9 févr. 2010 à 11:58, Richard Frith-Macdonald a écrit :

> 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.

These changes sounds good :-)

On a somewhat related matter, the next Étoilé release (initially  
planned for January but which won't probably happen before March) will  
require new releases of every gnustep core modules (base, gui, back  
and make). We will be ready once:
- we have an Étoilé theme ready based on the new GNUstep theming (Eric  
is currently working on that)
- our horizontal menu support is fully merged back into GNUstep  
(mostly means deleting code on our side and tweaking GNUstep to let us  
customize the menu more in-depth… e.g. menu title view. I have started  
to work on that)
- getting NSImage drawing methods work exactly as they do on Mac OS X  
(when the coordinates are flipped), see bug report #27782. I have a  
more recent patch which is probably more correct, fix extra issues I  
discovered in the meantime but which currently only works with Cairo  
and needs to be cleaned.
- gnustep-make detects the runtime version and exports a variable,  
which can be checked in GNUmakefiles, plus an identically named -D  
flag to support conditional #import in the headers. e.g.  
GNU_RUNTIME_VERSION=2 or RUNTIME_VERSION=gnu2. We discussed that a bit  
with Nicola at FOSDEM. The idea is to have the possibility to check  
whether we use libobjc or libobjc2 without having to resort to parsing  
the version number of libobjc.so.x in every project, where we build  
files conditionally based on the runtime version, or where we import  
this header: <http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/EtoileFoundation/Headers/runtime.h 
>.

The last important thing is that the next Étoilé release will require  
the Cairo backend. Which means, packaging Étoilé would be much easier  
if GNUstep makes Cairo its default backend for the next gnustep-gui/ 
back release.

Any comments? Does that sounds feasible to have a GNUstep unstable  
release in March/April?

Cheers,
Quentin.