Book Clarifications

...on topics from the GNUstep chapter (31) of Aaron Hillegass' Cocoa Programming on Mac OS X, Second Edition"

Introduction

The purpose of this section is to address users who have read Aaron Hillegass' book which, in Chapter 31, gives an account of GNUstep. Aaron's intentions were to give GNUstep wider exposure, which it has gotten because of his book, we are deeply grateful and thank him for this.

However, there are some inaccuracies in this Chapter that we would like to address. We would also like to give the user a updated look at GNUstep, since the chapter Aaron wrote seems to be using a rather old version.

Issues

All quotes come from Chapter 31 of the book "Cocoa Programming on Mac OS X, 2nd ed."

Page 417:
Developers often ask me if their code can be used on other platforms. My answer is usually 'Well... eh... not really'....
GNUstep is being used commercially by a number of companies and is distributed regularly on Debian and Gentoo. GNUstep also allows a developer to compile his/her application with almost no changes under most UNIX operating systems. While applications which use Foundation (gnustep-base) exclusively are portable to Windows (using Cygwin or MinGW), currently applications which utilize AppKit (gnustep-gui) may work, but will be unstable. The use of GNUstep-gui on Windows is currently very experimental.
Stephen Kochan briefly covers how to use GNUstep under Windows in his excellent book, "Programming in Objective-C". A windows installer for GNUstep can be found at ftp://ftp.gnustep.org/pub/gnustep/binaries/windows.
Page 417:
...That was a decade ago, and the group has yet to release a 1.0 version of this implementation called GNUstep.
Keeping in mind that many other open source projects have yet to release a "1.0" version, GNUstep isn't doing so badly. Also gnustep isn't versioned in the same way as many other projects. Each package in GNUstep has it's own version number.
For readers who don't know the versions are as follows:
- base (Foundation) version 1.10.x
- gui (AppKit) version 0.10.x -- scheduled for a 1.0 release later this year
- back (the backend) version 0.9.3
- Gorm (IB equivalent) -- currently at 1.0.x
- ProjectCenter (ProjectBuilder equivalent) -- version 0.4
The base library, for those readers who don't know, has been at 1.x since 04/08/2001.
Page 417:
The interface GNUstep creates is a decent copy of the NeXT UI. It was a slick look in 1994, but now the look and feel are neither like the Mac nor a normal X11 application.
GNUstep is themable, please see: The Étoilé Project. Camaelon is a theme engine for GNUstep which allows it's look to be made to look like almost anything you like. Also, one is forced to ask 'What does a normal X11 application look like?' Given the myriad of window managers (WindowMaker, elightenment, KDE, blackbox, openbox, fvwm, etc.. etc.. etc..) and the myriad of toolkits (GNOME/GTK, Xaw, Qt, etc.. etc.. etc..) the assumption that there is a "standard look" for X applications is incorrect. If Aaron was referring to GNOME or KDE consistency, there are Themes which can make GNUstep look close, and if not, they can be created.
The project is in the middle of determining how to integrate this functionality directly into GNUstep so that it is able to provide a more integrated solution. We are also considering integrating WildMenus directly into GNUstep to provide a more flexible way of displaying menus.
Page 417:
Porting your application from Mac OS X is difficult because the file formats for for nib files are different under GNUstep. (While the OpenStep API is open, Apple has kept the nib file format closed an proprietary.)
There are a number of tools available for GNUstep which can be used to ease the porting of the .nib files. The nib2gmodel tool, while not perfect, can be utilized to create a file which can simply be converted into a .gorm file with very little effort from the user. The .gmodel files it creates can also be used directly by applications compiled under GNUstep. In addition there is another XML based library called Renaissance which users can look into.
In addition to the above tools, now that GNUstep has an implementation of NSKeyedArchiver/NSKeyedUnarchiver, it is possible now to read the archives produced by IB when a nib is saved. Also, as of the most current release, Gorm, the InterfaceBuilder equivalent, is capable of loading and editing .nib files produced by IB, it can also save GNUstep objects as NIB files for use on OS X in IB.
Page 418:
The GNUstep team tends to be fairly aggressive about using the latest gcc, so you'll want to make sure the machine is up-to-date with a recent distribution.
This is completely false and actually the reverse is true. While Apple ties you to a specific version of gcc, the GNUstep team, in fact, takes great pains to make certain that the applications and frameworks build with previous versions of gcc down to 2.95. If you look in the ChangeLogs for any GNUstep package you will find that there are submissions which read like this:
```
"* SomeFile.m: Changes for compilation with gcc < 3.x."
```
This refers to modifications made so that versions of GCC less than 3.0 will work properly. Many users still have systems with gcc 2.95 on it and are still able to regularly compile using older versions of gcc. In addition the GNUstep team still uses a library called ffcall for compatibility with older compilers, even though the new compiler 3.x includes libffi which is built in.
Page 418:
The easiest way to install GNUstep is to use cvs from the terminal. Log in to the server and download the entire project.
There are tested and released tar/gz packages of all GNUstep source at ftp://ftp.gnustep.org/pub. It is also important to point out here that getting source from CVS is not advisable for the average user. Quite often there are issues with CVS versions of projects (in general, not just with GNUstep) since they are in development. There might be some experimental code or some code which might not work at all, again this is true with all projects, not just GNUstep. In general it is recommended that end users make use of the packages provided on the ftp site, which are considered to be official releases. These are generally better tested and more stable than what might be in CVS at any given point in time.
Page 417:
The tools are buggy and crash regularly.
The versions of both tools used by Aaron in his assessment of GNUstep were pulled from CVS (please see Issue 6) and were not official released of either the tools or the libraries. Since there were likely a lot of changes in both which would make it inherently unstable, it is unsurprising that he saw some crashes. Additionally, both Gorm and ProjectCenter and many other apps in GNUstep's standard suite have seen a great deal of work in the almost year and a half since he wrote this chapter (judging from the version of Gorm he seemed to be using, which wasn't a released version either).
Page 424:
Notice that the GNUstep people do not use #import. The implementation of #import in gcc was quite poor until the most recent release.
GNUstep applications can and do use #import. The only difference between Apple's gcc and standard gcc is in the runtime and the availability of objc++. Apple has been using the same implementation of import as the standard gcc despite the supposed "poor implementation". Also there are philosophical problems with import which are beyond the scope of this document.
The #import directive was officially undeprecated by the gcc team in version 3.4 and works fine 99% of the time in all previous versions of gcc which support #import.

Conclusion

While GNUstep still isn't perfect, it's current state is a lot better than Aaron describes. We urge you to take a look for yourself and let us know what you think.

Responses written by Gregory John Casamento, and edited by Alex Perez and Adam Fedor.