A Toolkit with GORM
OpenStep uses a slightly unusual mechanism for designing GUIs. Most other toolkits use one of the following two approaches:
- Programmatically generate the layout, with lots of instructions to create and position widgets. The Java AWT is an example.
- Specify the GUI layout in a markup language, often an XML dialect, and load it from the program. XUL works in this way.
The OpenStep approach is based on the programmatic generation plan. The missing ingredient that OpenStep adds is a mechanism for serializing and deserializing object graphs. While it’s possible to create these graphs manually, the traditional mechanism is to use the NeXT Interface Builder utility. The resulting files are usually called "NIBs" for their file extension (NIB, a contraction of NeXT Interface Builder).
GNUstep includes the Graphical Object Relationship Modeller (Gorm) as a replacement for the NeXT Interface Builder. The name reflects the fact that it can be used for more than just interface design. One common use is in document-driven applications. A window containing the view classes associated with a document and the model and controller logic is stored in the same NIB. When you want to create a new document, you simply instantiate a copy of the NIB, and continue.
One problem that GNUstep users traditionally encountered when porting code from NeXTStep or OS X was that NeXT’s binary NIB format was not well understood. The usual workaround was to run a program on the NeXT machine that would use the built-in libraries to read the NIBs and then the GNUstep libraries to write them. This wasn’t an optimal solution, though, since it required access to an OPENSTEP (or OS X) machine.
Starting with OS X 10.2, Apple introduced an XML format for NIB files. After some reverse-engineering, this is now quite well understood, and the latest version of GNUstep (and Gorm) can use it. This arrangement makes it a lot easier to port applications to and from OS X.