@c A FAQ for GNUstep
@c
@c This file uses the special commands @url{} and @email{}.  They are
@c handled by the doc/Makefile.

@iftex
@global@let@email=@i
@global@let@url=@samp
@end iftex

@c @ifinfo
@c @definfoenclose email, <, >
@c @definfoenclose url `, '
@c @end ifinfo

@chapter GNUstep Frequently Asked Questions with Answers

Written by Andrew McCallum @email{mccallum@@gnu.org}, with
contributions by Adam Fedor @email{fedor@@gnu.org}, 
Pascal Forget @email{pascal@@wsc.com}, Scott Christley
@email{scottc@@net-community.com}, Randy Chapman
@email{chapman@@u.washington.edu}, and Richrard Frith-Macdonald
@email{richard@@brainstorm.co.uk}.

Last updated @today{}
Please send corrections to @email{gnustep-maintainer@@gnu.org}.

The intended audience of this FAQ is future and present code developers
for GNUstep.  This FAQ serves a purpose complementary to the GNUstep WWW
pages---since it is written and maintained directly by those writing
code for GNUstep, it emphasizes (although not exclusively): (1)
technical details and organization, (2) the functionality is coded and
working now.  This FAQ is intended to provide a succinct document in
which to find GNUstep information without hype.

@section GNUstep General Information

@enumerate


@item @b{What is GNUstep?}

GNUstep is the Free Software Foundation's effort to implement NeXT
Software Inc.'s (now Apple) OpenStep Standard.  The project is not
finished, however some components are useable now.

The GNUstep project consists of the following sub-projects:

@itemize @bullet

@item GNU Objective C Compiler and Objective C Runtime Library -
Although not actually a component of GNUstep, GCC and the GNU
Objective C Runtime Library are integral to GNUstep, since they are used
to make every GNU Objective C program.

@item GNUstep Base Library - Code for non-graphical objects, such as
strings, collections, archiving support and distributed objects
messaging.  (Including functionality similar to OpenStep's
@samp{FoundationKit}.)

@item GNUstep GUI Library - Code for graphical objects used in making a
Graphical User Interface (GUI).  This includes buttons, sliders, text
fields, windows, menus, etc.  (Including functionality similar to
OpenStep's @samp{AppKit}.)

@item GNUstep DisplayGhostScript Server - A server that draws PostScript
graphics to the screen, and receives events from the keyboard and
mouse.  It is based on GhostScript.

@item GNUstep Interface Modeller Application - An application for
graphically assembling application interfaces.

@end itemize

More detailed information about each of these sub-projects can be found
in their own sections below.

There are several projects related to GNUstep that are not officially
part of the GNU project and GNUstep, but may become so in the future.
These include: the @samp{G3DKit} project, (contact Thomas Engle
@email{tsengel@@cip.informatik.uni-erlangen.de}); an application library
based on OpenGL, (contact Georg Tuparev
@email{Tuparev@@EMBL-Heidelberg.de}); and @samp{ProjectCenter}, a source
code management and development environment, (contact unknown).  If you
know of others, please contact the FAQ maintainer.

The initial target platforms for GNUstep are Linux and other UN*X's.
There has been some OS/2 WARP work, but I have not seen any ongoing work
on this platform yet, (contact McCallum if you are interested).


@item @b{What is the OpenStep standard?}

OpenStep is an Application Programming Interface (API) for creating
applications using the Objective C language.  It was published by NeXT
Computer Inc. in 1994.

OpenStep consists of three parts: the @samp{FoundationKit}, a library of
non-graphical objects; the @samp{AppKit}, a library of objects usful in
creating graphical applications; and @samp{Display Postscript}, an
interface for drawing to the screen using the PostScript graphics
language.

You can obtain a copy of the OpenStep standard in 

@itemize @bullet
@item texinfo at @url{http://www.dartmouth.edu/~ajones/Projects}.
@item HTML at @url{http://www.nmr.embl-heidelberg.de/GNUstep/GNUOpenStep}.
@item PostScript and RTF at @url{ftp://ftp.next.com/pub/OpenStepSpec/}.
@end itemize


@item @b{Who is currently involved in writing GNUstep code?}

For the sake of being social and getting to know each other, here is a
list of the folks who are currently, actively contributing GNUstep code.
The list includes a brief descriptions of each person's background and
involvement in the GNUstep coding efforts.

@itemize @bullet

@item Adam Fedor @email{fedor@@gnu.org} Co-Maintainer of the
GNUstep project, works on odd projects as tester
and code contributor. He also trys to keep up contacts with volunteers
and other outside enterprises that GNUstep may want to interoperate with.

@item Andrew McCallum @email{mccallum@@gnu.org} was appointed chief
maintainer of the GNUstep project by Richard Stallman in January 1996.
He has been involved and hacking in the NeXT community since NeXTSTEP
version 0.8; he has been working on GNU Objective C and the Base Library
since 1993.

@item Scott Christley @email{scottc@@net-community.com} is in charge of
the GUI library and the InterfaceModeler project, which is currently in
the design stages.  He is also the maintainer of the Objective-C
language and runtime for GCC.

@item Richard Frith-Macdonald  @email{richard@@brainstorm.co.uk} is
responsible in large part for the distributed objects system as well as
many other classes in the GNUstep base library.

@item Ovidiu Predescu  @email{ovidiu@@net-community.com} is doing a lot of work
on the GUI and XDPS backend, wrote the Makefile package, and also, along
with Mircea Ion Oancea wrote the Foundation extensions and the alternate
Foundation library libFoundation.

@item Pascal Forget @email{pascal@@wsc.com} is working on the GUI
Library in conjunction with Scott Christley.  He has worked with Randy
Chapman's DisplayGhostScript and X Windows as a GNUstep GUI backend.

@item Randy Chapman @email{chapman@@u.washington.edu} has been working
on the GNUstep DisplayGhostScript Server, adding DPS extensions to
GhostScript, including pswrap work.

@end itemize

There are many others who have made significant contributions to
GNUstep, but who are not currently contributing code, (such as Kresten
Thorup @email{krab@@next.com} and Paul Kunz
@email{paul_kunz@@slac.stanford.edu}).  For more information about
GNUstep history, see the GNUstep WWW pages.

There are also several others who have contributed individual classes to
GNUstep, but who are not actively contributing to general GNUstep work.
This list is not intended to be a complete list of GNUstep code
contributors; that information is available in each of the GNUstep code
packages.

There are also other code developers who are writing Objective C code
related to GNUstep, but for projects that are not officially part of the
GNU project and GNUstep.  We hope that some of these projects will join
the GNU project and GNUstep in the future.

Please send corrections to the FAQ maintainer.


@item @b{Is there a WWW site for GNUstep?  Are there mailing lists for GNUstep?}

There is a WWW site at @url{http://www.gnustep.org}, (and its mirror
@url{http://www.NMR.EMBL-Heidelberg.DE/gnustep}, that contains many
useful pointers. 

There are several mailing lists:

@itemize @bullet

@item @email{discuss-gnustep@@gnu.org} is a mailing list for general
discussion of GNUstep developments.  Announcements about GNUstep
progress are also made there.  Send mail to
@email{discuss-gnustep-request@@gnu.org} to subscribe.

To join, send mail to @email{discussion-request@@gnustep.org}.

@item @email{webmasters@@gnustep.org} is a mailing list for discussion of
the GNUstep WWW site.

To join, send mail to @email{webmasters-request@@gnustep.org}.

@item @email{g3dkit@@gnustep.org} is a mailing list for discussion of a
library for drawing 3D graphics; it is based on OpenGL and RenderMan.
The Free Software Foundation is hoping that this work can become an
official part of the GNU project and the GNUstep project.

To join, send mail to @email{g3dkit@@gnustep.org}.

@item There is also a private mailing list for the core active
developers of GNUstep.  Those people who contribute code and who are
interested in making and planning further contributions may join.
Please contact Adam Fedor @email{fedor@@gnu.org} if you would like to
make a contribution.

@end itemize


@item @b{What is the current state of the project?  When can I expect it to be completed?}

The Base Library is about 95 percent done.  Normal work can
already be done using the library.  The GUI library is about 65
percent done.  
More detailed information about the state of each of the sub-projects
can be found at the above mentioned web sites. 

With free software, you should never, ever, believe promises about when
a project will be finished.  ...However, that said: there are certain
GNUstep developers that are counting on having useful Base and GUI
libraries working by the end of Fall 1998.


@item @b{On what platforms will it run?}

The short answer is: On whichever platforms volunteers offer port it!
The main target platforms is free operating systems, namely GNU/Linux and
the Hurd.  Much of the code is OS-independent, and should port quite
easily to various UNIX-like OS's.  There has been interest in a port to
Linux on the Apple Macintosh, but we have not heard from any developers
working on this.

At least one of the current active developers is also working with
Windows NT.  There has been some interest in an OS/2 port, but I've seen
few code contributions for OS/2.


@item @b{How can I help?}

If you have a specific piece of functionality that you would like to
contribute, or if you would like to ask for suggestions about what
coding work you can do to help, contact the GNUstep Maintainers,
Andrew McCallum and Adam Fedor @email{gnustep-maintainer@@gnu.org}.

@end enumerate
@c GNUstep General

More detailed inforamtion about each of the GNUstep sub-projects can be
found below.

@section GNU Objective C Compiler and Objective C Runtime Library

@enumerate


@item @b{What is the Objective C Runtime Library?}

The Objective C Runtime Library provides C functions and data structures
required to execute an Objective C program.  An introduction to the
Objective C Language is provided at
@url{http://gemma.apple.com/techinfo/techdocs/rhapsody}.
The Frequently Asked Questions list for
@url{news://comp.lang.objective-c} can be found at @url{??}.

The GNU Objective C Runtime Library offers everything NeXT's runtime
does, including Categories, Protocols, @samp{+poseAs:}, thread-safety,
class initialization on demand, delayed loading of classes, and
initialization of static instances (such as @@""-style string objects). 

It also has several improvements over NeXT's implementation:

@itemize @bullet

@item NeXT's runtime requires an extra function call (objc_msgSend) for
each message that is sent; (the function looks up the receiving
instance's implementation of the method).  GNU's implementation is
faster because it does not use an extra function call.  Instead, it
inlines a short piece of code that makes two pointer hops into a method
dispatch table; because the code is inlined, it does not incur the
overhead of a function call.

@item When running in thread-safe mode, NeXT's runtime must aquire a
global mutual exclusion lock every time a message is sent; this is
extremely slow.  GNU's runtime, amazingly, sends messages just as fast
in thread-safe mode as it does in single-thread mode---the code path
does not contain even a single extra instruction!  The GNU runtime only
needs locks when certainly structures are written, not read; the
structures are written relatively infrequently: only at class
initialization and when @samp{+poseAs:} is called.

@item GNU's runtime provides ``selector-types'' along with each
selector; NeXT's does not.  A selector-type is a string that describes
the C variable types for the method's return and argument values.  Among
other uses, selector-types is extrememly helpful for fast distributed
objects implementations, (see GNUstep Base Library Section, below).

@item Many of the GNU functions have different names than their
corresponding NeXT functions; the GNU names conform to the GNU coding
standards.

@item GNU's runtime library has a new class heirarchy manipulating
method called @samp{-transmuteClassTo:}.  It can change the class of an
instance to a cousin class of the same instance-size.

@item NeXT's compiler, @samp{cc}, is based on an old version of
@samp{gcc}.  GNU's compiler is, of course, the latest version of
@samp{gcc}, and therefore contains all the latest enhancements.

@end itemize


@item @b{What is its current state of development?}

GNU's Objective C Runtime library has been stable and useable since
1993.  Enhancements continue to be made.

GCC contains the source for the GNU Objective C compiler and runtime
library.  It can be obtained from @url{ftp://prep.ai.mit.edu/pub/gnu},
or any other mirror of the GNU archives.  As far as I know, the GNU
Objective C Runtime runs on all, platforms on which GCC runs.

GCC version 2.8.0 or later is required for GNUstep. You can also use
egcs version 1.0.1 or later. Both compilers should contain the
thread-safe features. There are currently thread-safe backends for DEC
OSF/1, Solaris, IRIX, Linux, and WindowsNT.  Volunteers are solicited
for writing additional back-ends.

@item @b{Does it allow a mixture of Objective C and C++}

No.  Unlike NeXT's @samp{cc}, GNU GCC does not support source files
containing both Objective C and C++.  People at Cygnus have mentioned
that they would be willing to do the work---if they were paid for it, of
course.  Several people are interested in seeing this happen.  Send
email to @samp{discuss-gnustep@@gnu.org} and
@samp{gnu-objc@@gnu.org} if you are interesting in pushing this
issue, so that the efforts of all those people interested can be
coordinated.

Also, unlike NeXT's @samp{cc}, GNU GCC does not support the @samp{extern
"Objective-C"} construct.

@item @b{Where can I find more information?}

The FAQ associated with the newsgroup @samp{comp.lang.objective-c}
contains more information about GNU Objective C.

@end enumerate
@c GNU Compiler and Objective C Runtime Library


@section GNUstep Base Library

@enumerate

@item @b{What is the GNUstep Base Library?}

@include ../base/doc/base-desc.texi


@item @b{What is its current state of development?}

It is about 95 percent of the way to having all the OpenStep classes (and
the later OPENSTEP/Rhaspody classes) fully implemented.
Normal work can already be done using the library since the
missing 5 percent are the least-often-used classes and methods.
Over 60,000 lines of code have already been written.

Look at the STATUS file that comes with the distribution for additional
status information.

@item @b{In what ways is the Base Library different from OpenStep's FoundationKit?}

While the GNUstep base library is based upon an earlier `libObjects' library
which is arguably in some ways superior, work is generally being done to
make gstep-base entirely compatible with the NeXT/Apple implementation.

In general, the old `libObjects' classes are still available but many are no
longer used in the core OpenStep implementation.

The Base Library contains several enhancements:

@enumerate 

@item OpenStep has a single NSInvocation class, which is based on
sending a message to an object.  The GNUstep Base Library has NSInvocation,
but also has a heirarchy of Invocation classes with various capabilities.
Two of the Invocation subclasses can cause C functions to be called, instead of
sending messages to objects; these subclasses are useful when one would
otherwise have to write a new class and method to implement some simple,
stateless functionality.  Other subclasses of Invocation could hold
GUILE or TCL code to be run, or could record their invocation
information to a file.

All of them respond to a new method called @samp{-invokeWithObject:}
that is useful for enumerations.

@item I have been told that OpenStep's NSNotificationCenter is slow.
GNUstep's NotificationDispatcher class is based on interesting use of
linked lists and hash tables in such a way that it should be
comparatively very fast.

OpenStep notifications must be method selectors sent to objects.
GNUstep notifications can invoke an Invocation instead, thus taking
advantage of the flexbility and context-holding capability of Invocation
objects.

@item OpenStep takes a disconnected ``class forest'' approach to
collection classes.  GNUstep has all the OpenStep collection classes
and also has a separate hierarchy of collection classes that are
organized as a deep class heirarchy.  Because of the deep heirarchy,
there is a built-in uniformity of method names, and there are common
abstract superclasses in which to add new common functionality.  

Unlike OpenStep, the Base Library also has additional collection classes
for heaps, stacks, queues, trees and linked lists.  There is also a rich
variety of enumeration methods based on invocations.

@item OpenStep's archiving mechanism provides only one choice of backend
format.  By backend format, I mean a format for writing C types, such as
ints, floats and C strings.  The GNUstep implementation of NSArchiver
and NSUnarchiver provides hooks so that a subclass can provide a different
backend.

The Base Library also contains the libObjects archiving mechanism, which
has a clear separation between frontend and backend.  Different backends are
provided.  One backend writes in human-readable and human-editable ASCII
text, (including programmer-provided text name labels for each of the
items.)  Another writes in a compact, stream machine-independent bits.
A third writes in an even more compact stream of machine-dependent bits;
this is useful for distributed objects connections on machines of the
same architecture.

OpenStep's archiving system (NSArchiver/NSUnarchiver) implements forward
references, (that is, calls to @samp{encodeConditionalObject:} for which
the object argument has not yet been encoded, but will be encoded later.)
by making two passes through all the -encodeWithCoder: methods of the
objects to be encoded.
The libObjects archiving system, on the other hand, implements forward
references efficiently, without making two passes.  It does this by
using an object decoding method (@samp{-decodeObjectAt:..}) that
back-patches @code{id}-pointers when the conditionally encoded objects
are found in the coded stream.

@item OpenStep's distributed objects mechanism requires four network
``hops'' when sending and responding to each new method---one to send
the request, one for the server to request the method type from the
client, one for the client to respond with the method type, and one to
respond with the return value of the method call.  GNUstep distributed
objects takes advantage of the superior GNU Objective C runtime, which
includes the method type locally with the selector.  Since the method
type can already be found on the server, there is no need to ask the
client for the type, and GNU distributed objects takes two less network
hops.

@item OpenStep's distributed objects mechanism is based on a single
@i{Port} class.  By contrast, GNU distributed objects makes use of a
heirarchy of Port objects that will provide the different ``back-ends''
appropriate to different situations.  For example, the network back-end
for GNU distributed objects will be able to send messages using TCP,
UDP, local Unix sockets, or shared memory.

@end enumerate


@item @b{What are the features of GNU Distributed Objects?}

GNU Distributed Objects has many of the features of other distributed
objects implementations, but, since it is free software, it can be
ported to platforms for which other distributed objects implementations
are not available.

If you are interested in having it ported to a new platform, or if you
have any questions about it, please contact Adam Fedor,
@email{fedor@@gnu.org}.

The distributed object support classes are @b{NSConnection},
@b{NSDistantObject}, @b{NSPortCoder}, @b{NSPort}, @b{TcpPort}, @b{UdpPort}, and
@b{MachPort}.  Of the various Port backend's, currently only the the
TcpPort is in working order.


[NOTE: The GNU distributed object facilities have the same ease-of-use
as NeXT's; be warned, however, that they are not compatible with each
other.  They have different class heirarchies, different instance
variables, different method names, different implementation strategies
and different network message formats.  You cannot communicate with a
NeXT NSConnection using a GNU Connection.  

Here are some differences between GNU distributed objects and NeXT's
distributed objects: NeXT NSDistantObject asks it's remote
target for the method encoding types and caches the results; GNU
NSDistantObject gets the types directly from the local GNU "typed selector"
mechanism if the information is known locally and only queries the remote
target or caching encoding types when using a method that is not known to
the local process.  The NSProxy for the remote root object always has name 0
and, once set, you cannot change the root object of a NSConnection; the GNU
Proxy for the remote root object has a target address value just like
all other Proxy's, and you can change the root object as many times as
you like.  See the "lacking-capabilities" list below for a partial
list of things that NSConnection can do that GNU Connection cannot.]


Here is a partial list of what the current distributed objects system
can do:

@itemize @bullet

@item It can pass and return all simple C types, including char*, float
and double, both by value and by reference.

@item It can pass structures by value and by reference, return
structures by reference.  The structures can contain arrays.

@item It obeys all the type qualifiers: oneway, in, out, inout, const.

@item It can pass and return objects, either bycopy or with proxies.  An
object encoded multiple times in a single message is properly decoded on
the other side.

@item Proxies to remote objects are automatically created as they are
returned.  Proxies passed back where they came from are decoded as the
correct local object.

@item It can wait for an incoming message and timeout after a specified
period.

@item A server can handle multiple clients.

@item The server will ask its delegate before making new connections.

@item The server can make call-back requests of the client, and keep it
all straight even when the server has multiple clients.

@item A client will automatically form a connection to another client if
an object from the other client is vended to it. (i.e. Always make a
direct connection rather than forwarding messages twice, once into the
server, from there out to the other client.)

@item Servers and clients can detect port deaths (due to remote
application crash, for example) and close down gracefully, announcing
the closed connection to other objects who have requested notifications.

@item Exceptions that occur in the server (during the course of
servicing a request) are sent back to the client, and the exception is
then properly raised in the client's process.

@item Servers and clients can be on different machines of different
architectures; byte-order and all other architecture-dependent nits are
taken care of for you.  You can have SPARC, i386, m68k, and
MIPS---Linux, SunOS, Solaris, IRIX, AIX and HPUX machines all
distributed-object'ing away together in one big web of client-server
connections!  The library can be ported to other architectures and
operating systems also.  Please contact Adam Fedor,
@email{fedor@@gnu.org}, if you are interested in having a new
port of GNU Distributed Objects.

@end itemize

Here is a partial list of what the current distributed objects system
does @b{not} yet do: 

@itemize @bullet

@item  Run multi-threaded.

@item  Use Mach ports, pass Mach ports, pass Mach virtual memory.

@end itemize



@item @b{What is the general organization of the non-OpenStep, GNU classes?}

(This FAQ does not describe the OpenStep standard classes, because a
detailed description of those can be found in the OpenStep
documentation.)

Here are some of the public GNU classes.  See the source header files
for more information.

@format
The collection class heirarchy:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collection                 Root all the collection classes (abstract)
  Set                      Unordered collection, no duplicates
  Bag                      Unordered collection, may have duplicates
  KeyedCollection          Contents accessible by object key (abstract)
    Dictionary             Concrete implementation
    MappedCollection       One collection maps into another
  IndexedCollection        Contents accessible by integer (abstract)
    BinaryTree             Basic, sorted binary tree
      RBTree               Red-Black tree, sorted, more balanced
      SplayTree            Splay operation keeps tree balanced
    OrderedCollection      Can insert at arbitrary index (abstract)
      Array                Basic array
        Queue              First in, first out
        Stack              First in, last out
        GapArray           Efficient handle middle insert and delete
      LinkedList           More efficient than arrays for some ops

Strings (as in Smalltalk, part of the collection class heirarchy):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      ConstantString        Root of string classes, chars not changable
        String              contents can be changed
        *CString            Strings based on 1-byte characters

Writing/reading bytes, C-type variables, and connected groups of objects:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Stream                     Source and Destination for stream of bytes
  StdioStream              Stream based on FILE* (files, pipes, etc)
  MemoryStream             Stream based on memory buffer
CStream                    Write/Read C-type variables on stream
  TextCStream              use human-readable format
  BinaryCStream            use compact machine independent format
  RawCStream               use even more compact machine depedent format
Coder                      Write/Read groups of objects on CStream
  Encoder                  Writing
    Archiver               for files
    ConnectedEncoder       for distributed objects
  Decoder                  Reading
    Unarchiver             for files
    ConnectedDecoder       for distributed objects

Holding code to be run on request:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Invocation                 Contains code that can be run
  ArgframeInvocation       based on gcc __builtin_apply()
    MethodInvocation       invokes a method on an object
    ObjectMethodInvocation the method takes at least one object arg
  ObjectFunctionInvocation calls a function with type (id(*)(id))
  VoidFunctionInvocation   calls a functions with type (void(*)())

Posting information about happenings:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Notification               for posting information others may want
NotificationRequest        a record of an observers request
  NotificationInvocation   will be posted by invoking an Invocation
  NotificationPerformer    will be posted by -perform:withObject
NotificationDispatcher     distributes Notification's among requestors

Distributed Objects Support:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Connection                 between two machines on which messages sent
Proxy                      Representative of a remote object
Port                       A mailbox for packets
  InPort                   for receiving packets
  OutPort                  for sending packets
    Tcp*Port               based on TCP/IP
    Udp*Port               based on UDP/IP
    Mach*Port              based on Mach ports
Packet                     holds data and reply port
@end format


@item @b{Why don't we separate the OpenStep standard classes from the GNU-specific classes?}

Just like @i{GCC} has more features than ANSI C, @i{gawk} has more
features than @i{awk}, and the @i{GNU C Library} has more features than
standard C Libraries, also, @i{GNUstep} has more features than
@i{OpenStep}.  In all these cases, ``more features'' means some
combination of increased capabilities, and better time/space efficiency.
It is in keeping with the GNU tradition that GNU implementations are not
simply mindless copies of others standards, but that our implementations
include new improvements and creative solutions to previous annoyances.

In fact, Richard Stallman encourages innovation of this kind---not only
for the sake of better software---but also because it makes the legal
issues more clear: when the underlying implementation differs from the
proprietary implementation in significant, core, structural ways, it is
far more difficult for the proprietary entities to claim copyright
infringement.

But the far more exciting reason for structural differences is the
increased efficiency and features that come from the changes.  The item
above, ``@b{In what ways is the Base Library different from OpenStep's
FoundationKit?}'', explains some of the advantages that GNUstep's
organizational differences provide.

Many of these advantages are based on variations in class hierarchy, and
could not have been obtained by simply adding Category methods, or
subclasses to NeXT's structural organization.  Using the advantageous
GNU structures, providing the OpenStep standard interface on top of the
GNU implementations is quite straightforward, (and when the mechanism
is understood, quite clean, also).

By analogy, consider the GNU C Library's @i{stdio} functionality.  It is
based on a different underlying structure that provides new features not
found in standard @i{stdio} implementations.  A @i{FILE*} can be opened
on a memory string that automatically grows as necessary; a @i{FILE*}
can be opened on a Mach port, where available.  Using the generalized
underlying mechanism, it is straightforward to also implement the
standard @i{FILE*} opened on a UNIX file descriptor.

The GNUstep Array class, (for example), is implemented in much the
same way.  GNUstep has a generalized collection class hierarchy with a
deep structure that provides common super classes in which a programmer
can add new functionality across all collection classes at once.  It
also simply and powerfully ensures uniformity of method names and
semantics across all collection class methods.  It also provides more
efficient code sharing between classes.  The @i{Array} class is part of
the GNUstep collection classes hierarchy.

In summary, the GNU project has often found that, while adding new
features to standard programs and libraries often requires more thought
and source code than standard implementations, it is worthwhile because
of the advantages of (1) better features, (2) increased time/space
efficiency, and (2) legal clarity.  GNUstep is no exception.


@item @b{Where can I get a copy?}

The most recently released ``official'' version can be obtained from
@url{ftp://ftp.gnu.org/pub/gnu}.

The most recently released alpha version can be obtained from
@url{ftp://alpha.gnu.org/gnu/gnustep}.

You can use anonymous CVS to get hold of the latest (unreleased) version
of the software.  This may be unstable, but is usually better than the
most recent released version -

To use anonymous CVS, you must have an internet connection.  You should read
your CVS manual, but here are some instructions to get you started quickly -

1. Set set the CVSROOT environment variable -@*
@code{CVSROOT=":pserver:anoncvs@@cvs.net-community.com:/gnustep"; export CVSROOT}

2. Use the 'cvs login' command with the password 'anoncvs'

3. Checkout the source code -@*
@code{cvs -z3 checkout core}

Checking out 'core' gets you the standard GNUstep distribution - the base
library is in the 'base' subdirectory.

@end enumerate
@c GNUstep Base Library



@section GNUstep GUI Library

@enumerate


@item @b{What is the GUI Library?}

The GNUstep GUI Library is a library of objects useful for writing
graphical applications.  For example, it includes classes for drawing
and manipulating graphics objects on the screen: windows, menus,
buttons, sliders, text fields, and events.  There are also many
peripheral classes that offer operating-system-independent interfaces to
images, cursors, colors, fonts, pasteboards, printing.  There are also
workspace support classes such as data links, open/save panels,
context-dependent help, spell checking.

It provides functionality that aims to implement the @samp{AppKit}
portion of the OpenStep standard.  However the implementation has
been written to take advantage of GNUstep enhancements wherever possible.


@item @b{Explain the organization of the front- and back-ends.}

The GNUstep GUI Library is divided into a front- and back-end.  The
front-end contains the majority of implementation, but leaves out the
low-level drawing and event code.  A back-end can override whatever
methods necessary in order to implement low-level drawing event
receiving.  Different back-ends will make GNUstep available on various
platforms.  The default GNU back-end will run on top of X Windows and
the DisplayGhostScript Server.  Other back-ends could allow GNUstep to
run on OpenGL, OS/2, and WIN32 graphics/event platforms.  Much work
will be saved by this clean separation between front- and back-end,
because it allows different platforms to share the large amount of
front-end code.

The front-end does not specify what mechanism to use in order to "plug
in" the back-end---that is the back-end implementor's choice.  At least
two backends will use @samp{+poseAs:} method, for example, running
@samp{[XDPSWindow poseAs: [NSWindow class]]}.  Using @samp{+poseAs:} is
more flexible than using Categories because it allows the the back-end
implementor to choose what to override in the front-end, instead of
having the interface between front- and back-end fixed by the front-end.


@item @b{What is the current state of development of the front-end?}

Many of the classes are well implemented, if not thouroughly tested.
See the GNUstep web sites and read status information contained in the
distribution for the most up-to-date information.

@item @b{What is the current state of development of the X/DPS back-end?}

Many of the classes are well implemented, if not thouroughly tested.
See the GNUstep web sites and read status information contained in the
distribution for the most up-to-date information.

@item @b{Where can I get a copy?}

At the same place as the Base library.

@end enumerate
@c GNUstep GUI Library


@section GNUstep DisplayGhostScript Server

@enumerate

@item @b{What is the Display Ghostscript Server?}

It is a free implementation of a Display PostScript server based on the
ghostscript program by Aladdin software.

@item @b{What is its current state of development?}

GNU contracted with Aladdin software to add some key features to
ghostscript so it could be used as a DPS server. This work has mostly
been done, and we are working on integrating the changes into our system
and taking advantage of them. The person doing this is extremely busy,
so there is no set completion date.

@item @b{What is the relationship between the Display Ghostscript Server and X Windows?}

Display Ghostscript runs on top of X Windows.

@end enumerate
@c GNUstep DisplayGhostScript Server



@section GNUstep Interface Modeller Application

@enumerate

@item @b{What is the Interface Modeller?}

Interface Modeller, in its simplest form, is an application for visually
constructing and prototyping graphical user interfaces.  At a more
abstract level, it is a tool for connecting instances of Objective C
classes to create a graph of objects; this graph is a model of an
executable program that Interface Modeller can save to a file to be
loaded and executed later outside of Interface Modeller.


@item @b{What is its current state of development?}

It is in the specification stage; no code has been written yet.  The
current specifications are available through the GNUstep WWW pages.

@end enumerate
@c GNUstep IM

@c ****************************************************************
@c Compiling
@section Compiling the GNUstep package

@enumerate

@item @b{How do I compile GNUstep on my machine?}

Read the file @file{GNUstep-HOWTO}, which comes with the GNUstep
distribution, and also is available separately on the GNUstep ftp sites.

@item @b{Are there any precompiled packages available?}

Sort of. You can check the debian site for preconfigured GNUstep
packages.

@item @b{I get an error compiling mframe.m in gnustep-base}

This occurs on some GNU/Linux systems.  You'll need to change the
optimization level, usually like this:
@example
make OPTFLAG=-O
@end example

@item @b{Can I run NeXT OPENSTEP or Apple Rhapsody programs on GNUstep?}

You can't run these programs on GNUstep, but if you have the source
code for the programs, you should be able to port them to GNUstep and
compile them. Whether or not you will be able to run them depends on how
complete GNUstep is at the time.

@item @b{Is it easy to port OPENSTEP and Rhapsody programs to GNUstep?}

It is probably easy for simple programs. You'll have to rewrite the
Makefiles as GNUstep uses a slightly different format.  You will also
have to translate the NIB files (if there are any) to GNUstep model
files using the nib2gmodel program in the GNUstep distribution
(gstep/gui/Model).

@end enumerate


@ignore
[Notes to FAQ contributors: Be succinct.  Stick to the facts.  Emphasize
technical features that are already implemented; avoid writing about
vague features without concrete ideas about their implementation.  Your
audience is future and present code contributors to GNUstep, not
managers or publicity people.]
@end ignore

@format


All trademarks mentioned on in this FAQ belong to their owners.
@end format

@c Local variables:
@c page-delimiter: "^\n\n"
@c time-stamp-active: t
@c time-stamp-format: "%d %b %y"
@c time-stamp-line-limit: 50
@c time-stamp-start: "Last updated[ \t]+"
@c time-stamp-end: "\\."
@c end:
