GNUstep Frequently Asked Questions with Answers
***********************************************

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

   Last updated 3 November 1998 Please send corrections to
<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.

GNUstep General Information
===========================

  1. 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:

        * 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.

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

        * 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 `AppKit'.)

        * 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.

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

     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 `G3DKit' project, (contact
     Thomas Engle <tsengel@cip.informatik.uni-erlangen.de>); an
     application library based on OpenGL, (contact Georg Tuparev
     <Tuparev@EMBL-Heidelberg.de>); and `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).

  2. 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 `FoundationKit', a library of
     non-graphical objects; the `AppKit', a library of objects usful in
     creating graphical applications; and `Display Postscript', an
     interface for drawing to the screen using the PostScript graphics
     language.

     You can obtain a copy of the OpenStep standard in

        * texinfo at `http://www.dartmouth.edu/~ajones/Projects'.

        * HTML at
          `http://www.nmr.embl-heidelberg.de/GNUstep/GNUOpenStep'.

        * PostScript and RTF at `ftp://ftp.next.com/pub/OpenStepSpec/'.

  3. 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.

        * Adam Fedor <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.

        * Andrew McCallum <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.

        * Scott Christley <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.

        * Richard Frith-Macdonald  <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.

        * Ovidiu Predescu  <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.

        * Pascal Forget <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.

        * Randy Chapman <chapman@u.washington.edu> has been working on
          the GNUstep DisplayGhostScript Server, adding DPS extensions
          to GhostScript, including pswrap work.

     There are many others who have made significant contributions to
     GNUstep, but who are not currently contributing code, (such as
     Kresten Thorup <krab@next.com> and Paul Kunz
     <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.

  4. Is there a WWW site for GNUstep?  Are there mailing lists for
     GNUstep?

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

     There are several mailing lists:

        * <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
          <discuss-gnustep-request@gnu.org> to subscribe.

          To join, send mail to <discussion-request@gnustep.org>.

        * <webmasters@gnustep.org> is a mailing list for discussion of
          the GNUstep WWW site.

          To join, send mail to <webmasters-request@gnustep.org>.

        * <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 <g3dkit@gnustep.org>.

        * 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
          <fedor@gnu.org> if you would like to make a contribution.

  5. 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.

  6. 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.

  7. 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
     <gnustep-maintainer@gnu.org>.


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

GNU Objective C Compiler and Objective C Runtime Library
========================================================

  1. 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
     `http://gemma.apple.com/techinfo/techdocs/rhapsody'.  The
     Frequently Asked Questions list for `news://comp.lang.objective-c'
     can be found at `??'.

     The GNU Objective C Runtime Library offers everything NeXT's
     runtime does, including Categories, Protocols, `+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:

        * 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.

        * 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 `+poseAs:' is called.

        * 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).

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

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

        * NeXT's compiler, `cc', is based on an old version of `gcc'.
          GNU's compiler is, of course, the latest version of `gcc',
          and therefore contains all the latest enhancements.

  2. 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
     `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.

  3. Does it allow a mixture of Objective C and C++

     No.  Unlike NeXT's `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 `discuss-gnustep@gnu.org' and
     `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 `cc', GNU GCC does not support the `extern
     "Objective-C"' construct.

  4. Where can I find more information?

     The FAQ associated with the newsgroup `comp.lang.objective-c'
     contains more information about GNU Objective C.


GNUstep Base Library
====================

  1. What is the GNUstep Base Library?

     The GNUstep Base Library is a library of general-purpose,
     non-graphical Objective C objects.  For example, it includes
     classes for strings, object collections, byte streams, typed
     coders, invocations, notifications, notification dispatchers,
     moments in time, network ports, remote object messaging support
     (distributed objects), event loops, and random number generators.

     It provides functionality that aims to implement the non-graphical
     portion of the OpenStep standard.  In many cases, the `NS*' classes
     are implemented as wrappers around more featureful GNU classes.

  2. 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.

  3. 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:

       1. 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
          `-invokeWithObject:' that is useful for enumerations.

       2. 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.

       3. 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.

       4. 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
          `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 (`-decodeObjectAt:..') that back-patches
          `id'-pointers when the conditionally encoded objects are
          found in the coded stream.

       5. 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.

       6. OpenStep's distributed objects mechanism is based on a single
          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.


  4. 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,
     <fedor@gnu.org>.

     The distributed object support classes are NSConnection,
     NSDistantObject, NSPortCoder, NSPort, TcpPort, UdpPort, and
     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:

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

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

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

        * 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.

        * 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.

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

        * A server can handle multiple clients.

        * The server will ask its delegate before making new
          connections.

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

        * 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.)

        * 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.

        * 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.

        * 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, <fedor@gnu.org>, if
          you are interested in having a new port of GNU Distributed
          Objects.

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

        * Run multi-threaded.

        * Use Mach ports, pass Mach ports, pass Mach virtual memory.

  5. 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.

     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

  6. Why don't we separate the OpenStep standard classes from the
     GNU-specific classes?

     Just like GCC has more features than ANSI C, gawk has more
     features than awk, and the GNU C Library has more features than
     standard C Libraries, also, GNUstep has more features than
     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, "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 stdio functionality.  It
     is based on a different underlying structure that provides new
     features not found in standard stdio implementations.  A FILE* can
     be opened on a memory string that automatically grows as
     necessary; a FILE* can be opened on a Mach port, where available.
     Using the generalized underlying mechanism, it is straightforward
     to also implement the standard 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 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.

  7. Where can I get a copy?

     The most recently released "official" version can be obtained from
     `ftp://ftp.gnu.org/pub/gnu'.

     The most recently released alpha version can be obtained from
     `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 -
     `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 -
     `cvs -z3 checkout core'

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


GNUstep GUI Library
===================

  1. 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 `AppKit'
     portion of the OpenStep standard.  However the implementation has
     been written to take advantage of GNUstep enhancements wherever
     possible.

  2. 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 `+poseAs:' method, for example,
     running `[XDPSWindow poseAs: [NSWindow class]]'.  Using `+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.

  3. 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.

  4. 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.

  5. Where can I get a copy?

     At the same place as the Base library.


GNUstep DisplayGhostScript Server
=================================

  1. What is the Display Ghostscript Server?

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

  2. 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.

  3. What is the relationship between the Display Ghostscript Server
     and X Windows?

     Display Ghostscript runs on top of X Windows.


GNUstep Interface Modeller Application
======================================

  1. 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.

  2. 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.


Compiling the GNUstep package
=============================

  1. How do I compile GNUstep on my machine?

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

  2. Are there any precompiled packages available?

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

  3. 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:
          make OPTFLAG=-O

  4. 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.

  5. 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).




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

