The GNUstep Objectives describe the 'official' position regarding the direction and goals of GNUstep.
GNUstep's goal is to create a free, superior development environment based on and inspired by the OpenStep standard developed by NeXT Computer Inc. (now Apple Computer Inc.) and the OPENSTEP implementation of this standard. Apple has continued to update this specification in the form of Cocoa and Mac OS X, and there is no hope of GNUstep guaranteeing that we shall maintain compatibility with an Apple API that is constantly changing.
Our target implementation for the core libraries is the OpenStep standard and OPENSTEP implementation. However, we do consider changes and additions to this API under the following circumstances.
- We add methods and classes, either from Cocoa or our own extensions, if they add substantial value and don't interfere with OpenStep and/or Cocoa compatibility.
- We won't remove things, even if they have been removed by Apple.
- Where there is a real problem with a change, we find a technically superior work-around. In rare cases, this might involve a change in the original OpenStep API
Note that it is not the responsibility of the main developers to achieve or maintain Cocoa compatibility! We accept patches and bug reports that detail Cocoa additions and/or changes and we do our best to integrate these changes as long as they do not conflict with the previously stated rules.
We typically code to the most recent documented API we can find. Where the latest documentation actually conflicts with the original, the latest version generally wins. Better or more explicit Cocoa documentation wins over ambiguous OpenStep documentation.
In some cases, classes or parts of classes have been added that are clearly specific to a particular platform. Since we provide a cross-platform solution, we will probably not add these classes to our core libraries. Although we do accept submission of code for these classes and perhaps put them in a separate library
We may add non-standard extensions that people might find useful, although these are generally contained in a separate library.
We also may be able to provide more comprehensive or flexible solutions than are available in Mac OS X. In this case, classes or functionality may be missing from the core libraries, but may be available in other libraries.
For instance, instead of adding the 20 or so trivial scripting classes to the base/Foundation library for scripting, we have StepTalk, Rigs, and gnustep-guile.
GNUstep has split the GUI into a front-end GUI "interface" and a backend window-server specific implementation. With this architecture it is possible to support several window-server backends (DPS, X, libart, Windows). Our main interest is supporting the Display PostScript drawing model (at least conceptually), but we may support other models in the future.
Look and Feel
While we are not fanatical about the look and feel of a system, one of the primary reasons we are all working on an OpenStep system is the superior design and consistent interface defined in the specification. We will generally avoid specifying a look for GNUstep, except where not doing so may degrade the consistency of the interface. However, the feel of the interface is more deeply embedded in the specification and we agree that this aspect of an interface design is vital to the aesthetic appeal and user-friendliness of a system. We in general like the NeXT GUI, at least the fact that it does provide a uniform look and feel, and will probably continue to support this style.