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
.