GNUstep Frequently Asked Questions for Users
********************************************

Last updated . Please send corrections to gnustep-maintainer@gnu.org. Also look at the (developer) FAQ for more developer oriented questions.

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

What is GNUstep?
----------------

GNUstep is the Free Software Foundation's effort to implement NeXT Software Inc.'s (now Apple Inc.) OpenStep Standard.  The project is not finished, so some parts are not as polished as they could be.

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 useful 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 from the GNUstep web site http://www.gnustep.org or it's mirror sites.

What platforms does GNUstep run on?
-----------------------------------

See the list of supported platforms at http://www.gnustep.org/information/machines_toc.html for information on what machines GNUstep builds on and what the status of the ports is. Probably a few days porting to any other Unix system where current gcc/egcs compilers and gdb debugger work.

Does GNUstep run on Windows?
----------------------------

The primary targets for GNUstep are free 'Unix' platforms such as GNU/Linux.

That being said, the base library should run on Windows-NT,98 with the Cygwin unix emulation library from Cygnus (http://sourceware.cygnus.com/cygwin/) or the MinGW libraries.  At present there are a few problems with networking (Distributed Objects) support, but the library is believed to work.

The gui library needs a win32 backend library to work under Windows-NT.  The backend library is a thin layer that converts the GNUstep methods to handle drawing of GUI elements to calls to the win32 API.  This is a project looking for a volunteer.

The application-wrapper used for GNUstep already allows for multiple binaries to be stored for different systems, so you should be able to write once, deploy anywhere.

What is GNUstep's position towards KDE and the GNOME project?
-------------------------------------------------------------

You can use GNUstep with GNOME and/or KDE.  GNUstep displays on top of X11. You can still do programming in C (since Objective-C is just a super-set of C), and when (if?) GCC gets around to it, you'll be able to mix C++ and Objective-C code in the SAME file.

GNUstep, is much more than a window manager or desktop environment. It frees you to develop cross-platform applications without the work of developing an OS independent framework from scratch. It gives you lots of basic functionality, from Font Panels to Unicode strings to Distributed Objects.

Which Foundation Library can I use?
-----------------------------------

That depends ...

If you only want to use the database package - gnustep-db, you can use either the gnustep base library or libFoundation.

If you want to develop/use GNUstep gui applications, you must use the gnustep-base library since libFoundation is (13-Feb-2000) missing much essential functionality.

How can I get GNUstep?
----------------------

Get the HOWTO from http://www.gnustep.org/resources/documentation/GNUstep-HOWTO Get the latest release from ftp://ftp.gnustep.org. If you're really adventurous, get the latest snapshot by anonymous ftp from ftp://ftp.gnustep.org:/pub/daily-snapshots

Use anonymous CVS to keep up to date - instructions are in the HOWTO.

How do you run GNUstep?
-----------------------

You are presumably under the misapprehension that GNUstep is some sort of program or window manager.

It isn't.

GNUstep is a whole load of things - primarily a set of libraries for developing software.

At present, it's those libraries, plus various command-line based support tools and service providing daemons, plus various GUI development tools, a GUI desktop/workspace application, etc.

At no stage will you ever 'run' GNUstep - you will run applications and tools and will make use of it's services (though at some point you may well find packages distributed as 'GNUstep' systems in the way that you get 'Linux' systems packaged today).

If you want to see a sample GUI application running you need to build GNUstep and look at the example applications in the gnustep-examples package.  Build 'Finger' or 'Ink' and start it with 'openapp Finger.app' or 'openapp Ink.app'

To look best - use WindowMaker (the currently preferred GNUstep window manager) as your window manager.

Is there a web site?
--------------------

See http://www.gnustep.org/.

When is GNUstep intended to be available?
-----------------------------------------

It's usable now. Releases are made about every six months. However, if you are a serious developer, it's probably best to use the latest snapshots.

What is usable?
---------------

  * gnustep-make does pretty much what the makefiles in NeXTstep do.

  * gnustep-base (Foundation) stuff should work fine for almost all projects.

  * gnustep-db is only EOF-1.0 compatible but should work OK.

  * gnustep-gui (AppKit) has a lot working but there is still stuff missing.

  * DGS (Display Ghostscript) is usable but slow.

What does this mean for users? Many applications will run quite well. Applications that require very complex drawing and some unusual features may not.

Compiling and Installing
========================

How do I compile GNUstep on my machine?
---------------------------------------

Read the file GNUstep-HOWTO, which comes with the GNUstep distribution (gnustep-make), and also is available separately on the GNUstep web site.

Are there any precompiled packages available?
---------------------------------------------

Check http://www.gnustep.org/resources/sources.html for links to RPMS. Debian packages are also available.  You can check the debian site(s) for preconfigured GNUstep packages. Also check the BSD sites for GNUstep ports.

What are these type and size warnings?
--------------------------------------

These warnings:

     /usr/bin/ld: warning: type and size of dynamic symbol
     `__objc_class_name_NSConstantString' are not defined

are a common occurence and are due to a mismatch between gcc and ld. They don't do any harm so they can be safely ignored. They have been fixed in GCC version 3.1.

Compatibility and Layout
========================

Can I run NeXT OPENSTEP or MacOSX 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.

Is GNUstep following Changes to OpenStep and MacOSX?
----------------------------------------------------

Yes, gnustep-base already contains the documented changes in the Foundation library.  GNUstep aims to be compatible with both the OpenStep specification and with MacOS-X It should be easy to write an application that compiles cleanly under both GNUstep and Cocao.

Do we have to have the NeXTstep look and feel?
----------------------------------------------

GNUstep is aiming for something like the NeXTstep-3.3 look and feel. Although we don't want to force anyone into this, a lot of the power and ease of use comes from this feel. The look of GNUstep is something different - buttons and other widgets can look different but still act the same way. We hope to implement themes which will allow this. Actually we're hoping someone will volunteer to do it.

What's up with the directory structure?
---------------------------------------

First of all, GNUstep uses a slightly different directory structure than NeXT or MacOSX. Part of this is historical, part is because we can't do things the same way (see Why not use Frameworks?).

GNUstep also stores libraries and binaries in subdirectories based on the operating system and cpu. This is so you can compile and store binaries for different systems in the same directory structure. MacOSX uses Fat binaries to accomplish this (another reason we do it differently). If you want, you can get rid of this using the --enable-flattened option to the gnustep-make package.

Why not use Frameworks?
-----------------------

Frameworks are much more difficult to port and to use, and are very unnatural on a unix system - extremely unnatural on Windows. In a framework, the shared dynamic library is inside a framework wrapper directory.  Because of this, the dynamic linker can't find it.

We have frameworks, so how do we work around that? Well, we build dynamic links from a directory inside the dynamic linker path into the framework, which work, but then you can't move the framework anywhere else on the system, otherwise you break the link, and nothing will find the framework any longer!

On systems without dynamic links, like Windows, we can't even do this! We have to copy the library from the framework into the dynamic linker path, but that is simply a shared library then!  Absolutely no difference.  You put the dynamic library in a system directory in the dynamic linker path, and associate with that library a resource directory.

I think OpenStep for Windows did that, and still called them frameworks. Oh well we can do the same then, and call our libraries frameworks.

In a shared library, the shared dynamic library is in a directory which is in the path to the dynamic linker.  the dynamic linker can find it very easily.  this is how all shared and static libraries work on Unix systems, on Windows systems and possibly on most system at all.

Moreover, the OpenStep API requires us to provide some stuff for frameworks, like creating and registering automatically a framework object each time a framework is used (linked at runtime, or linked into the app), and attaching to it the list of classes inside the framework - which are not particularly trivial to implement - they depend on playing with the linker and the object file format - and might produce troubles when porting. And we never use these facilities.

For Apple MacOSX sure it's easier. They can modify the system linker, compiler, the system dynamical linker. They always know on which platform they are working (their own), etc.  They can modify the system to support frameworks natively.  Easy that way.

But GNUstep is meant to run on many different platforms, platforms which we don't control (Windows, Sun Solaris, Darwin, GNU/Linux, Unix variants) and which have different linkers and do not support frameworks natively.  On some systems it's difficult to just load a bundle or compile a shared library!

So building the core libraries as 'libraries' means that it's much easier to port them, and it's much more difficult to break them.

Sure, frameworks have a bundle of resources associated with it - but we can very easily associate a bundle of resource with a shared library, no reason why not.  We are doing it.

So please note that GNUstep libraries are meant to be much similar to MacOS X frameworks.  They are composed of a shared library and associated with a bundle of resources.  There is a difference in terminology, in where the resources are installed, and possibly a slight difference in the NSBundle API to get to the resource bundle (anyway, it's a one line difference between MacOSX and GNUstep, so it looks like very easy to #ifdef).

In other words, GNUstep libraries are meant to basically do the same as frameworks do on MacOSX, but to be portable to strange platforms (such as Windows).

Troubleshooting
===============

Problems compiling
------------------

If you get something like

     plmerge: error while loading shared libraries:
     libgnustep-base.so.1: cannot open shared object file: No such file or directory

This means your GNU make is broken on your system. Try this:

     make LD_LIBRARY_PATH=$LD_LIBRARY_PATH

You could also be having problems with gcc. gcc 2.96 does not work (Mandrake 8.1, perhaps others). Use a different compiler, like gcc 3.x.

Problems with Alt key
---------------------

If you are using WindowMaker, it's possible it is grabing this key and using it for itself. To check, open Window Maker's WPrefs and go to the Mouse Preferences. Then use another value for the "Mouse grab modifier" (bottom right). That will allow you to alt-drag things.