...on topics from the GNUstep chapter (31) of Aaron Hillegass' Cocoa Programming on Mac OS X, Second Edition
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.
All quotes come from Chapter 31 of the book "Cocoa Programming on Mac OS X, 2nd ed."
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.Developers often ask me if their code can be used on other platforms. My answer is usually 'Well... eh... not really'....
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....That was a decade ago, and the group has yet to release a 1.0 version of this implementation called GNUstep.
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.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.
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.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.)
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 3.x. Gcc 4.x series or clang are suggested, but gcc 3.4 is regularly tested. At the time of the writing of the book, actually, GNUstep ensured compatibility down to gcc 2.95.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.
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.The easiest way to install GNUstep is to use cvs from the terminal. Log in to the server and download the entire project.
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).The tools are buggy and crash regularly.
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.Notice that the GNUstep people do not use #import. The implementation of #import in gcc was quite poor until the most recent release.
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. It should be noted that, before publication, Aaron did make an effort to have the chapter reviewed by the GNUstep team. This set of responses is not an idictment or accusation of Aaron, we very much appreciate his efforts as well as the efforts of those on the team who took the time to review the material. Thank you.
Responses written by Gregory John Casamento, and edited by Alex Perez and Adam Fedor.