Re: Some questions about GNUStep

[David Chisnall]

On 14 Jun 2010, at 18:29, Philippe Laporte wrote:

> Hi all,
> 
> In order to figure out how to best contribute to the development efforts, I 
> have a few questions:
> 
> How far are you for MAC OS X 10.5 level support in the AppKit?

GNUstep development focusses on stuff that the developers need or want, so it's 
hard to compare to a specific OS X version.  For example, in Foundation, we got 
some 10.6 classes (e.g. NSCache) and methods (e.g. the array iteration using 
blocks) quickly, but some stuff from 10.4 (e.g. NSLocal) is missing.

In AppKit, probably the biggest omission currently is Bindings.  These work in 
the simplest cases, but we are missing some of the more complex classes.  We're 
also missing newer view classes, like NSCollectionView and NSPredicateEditor / 
NSRuleEditor.  

Our CoreGraphics implementation is currently being worked on by Eric as part of 
the Google Summer of Code and is starting to look usable.  Unlike the existing 
drawing back ends, it supports layers, which will make implementing at least a 
subset of CoreAnimation relatively easy (implementing the complex transitions 
will be a bit harder, but not too hard, just time-consuming).

> Has anyone started retargeting to other than X11 for Linux, like SDL?

There was a DirectFB back end floating around a while ago, but I'm not sure 
what happened to it.  The GNUstep back end basically has three responsibilities:

1) Creating and managing windows and windowing system specific resources.
2) Handling events.
3) Drawing.

Currently, these are more or less separated out into different classes, but 
they have some interdependencies.  Part of Eric's GSoC project is to separate 
out some of this so that we can use Opal (CoreGraphics implemented on top of 
Cairo) for drawing and plug in different things for handling events and 
creating windows.  

This is particularly useful for MS Windows; the current back end there shares 
no code with the X11 back ends, but Cairo works well on Windows so we should be 
able to share all of the drawing code between platforms and only maintain 
separate window management and event delivery code.  

Cairo also works with SDL (and anything else that can draw a pixmap to the 
screen), so we could potentially create an SDL back end too.  This might be of 
interest for an WebOS port, especially once we have a partial UIKit 
implementation (which really needs CoreGraphics and CoreText, and at least some 
of CoreAnimation to be useful).  

> How do you avoid needing Core Foundation?

Very easily.  Apple bought NeXT to replace their ageing MacOS with something a 
bit less archaic.  They used NeXT's OPENSTEP OS as the core of OS X, rewrote 
some of the display stuff, tweaked the UI, and rebranded the OpenStep APIs as 
Cocoa.  The 'step' in GNUstep comes from the fact that the project was 
originally created to implement OpenStep.

Core Foundation was created by Apple by factoring out some bits of the 
Foundation framework into something that both Cocoa, the API they inherited 
from NeXT, and Carbon, the API that was based on the Classic MacOS Toolkit, 
could use.  CF basically turns some methods from Foundation classes into 
functions.  These functions begin with a macro that tests whether they are 
really instances of the class in question, and if they aren't then they invoke 
the normal Objective-C message send mechanism.

If you call the CF functions with instances of the classes that they expect, 
then they are faster than doing a message send.  If you call them with other 
objects, such as subclasses of the classes in question, then they are slower 
(because they are still doing the message send, just via a layer of 
indirection).  

We don't use CoreFoundation inside GNUstep because there is no point.  We don't 
support Carbon, so there was no need to bother factoring the stuff out of 
Foundation.  We also make quite heavy use of subclasses for optimized versions 
of classes, so there is little benefit from avoiding the dynamic lookup.  Apple 
implements the same kind of thing as an ad-hoc class system inside 
CoreFoundation, giving lots of complexity for the perceived benefit of not 
having to link libobjc.

We do, however, provide CoreBase, which is a wrapper around our Foundation 
implementation designed to make porting stuff that uses CoreFoundation to 
GNUstep easier.  The interfaces are the same, although calling the CF*() 
functions will be slower than just doing a message send.  You will also find a 
make_c_interface tool in svn which can spit out a CF-style C interface to an 
Objective-C class.

By the way, with the new GNUstep runtime and some custom optimisation passes 
(see libobjc2/opts/) we can now do safe lookup caching and speculative 
inlining, so we will get absolutely no performance benefit from the CF 
approach, because we can make the compiler do in the general case what CF does 
in a few specific cases.

> What exactly is in core/gui/Headers/Additions/GNUStepGUI?

Stuff that is not part of the OpenStep / Cocoa APIs.  If you want code that 
runs on both GNUstep and Cocoa, without using any GNUstep stuff on OS X, don't 
#import the stuff in the Additions directories.

David

-- Sent from my STANTEC-ZEBRA