gslib backend update

[BALATON Zoltan]

Hello,

A new version of the gslib patch is available at
http://goliat.eik.bme.hu/~balaton/gnustep/gnustep-back-gslib-3.patch.gz

This is still _not_ for the general public, it may be interesting to
backend developers though. It contains the following changes:
* Now link with GNU Ghostscript 7.05
 - No patch needed
 - Use the following makefile:
   http://goliat.eik.bme.hu/~balaton/gnustep/makefile
   (To build do 'make STDDIRS; make libgslib.a')
* Patch against cvs of May 18 12:00 CEST
 - Apply to back, set GHOSTSCRIPTDIR in config.make, configure with
   --enable-graphics=gslib, set dspformat in Source/gslib/GSGSContextX11.m
   (for explanation see GHOSTSCRIPTDIR/src/gdevdsp.h)
* Uses the new "display" ghostscript device which should be portable. It
  currently renders to an XImage though.
* Most of the code is now platform independent (except NSBeep). Dependencies
  on X are separated to a category to help in supporting MS Windows.
* Drawing now appears correctly and in the right window at least on my
  system (dspformat is hardcoded).

The major shortcoming currently which prevents real use is the lack of
font and text handling. I plan to work on this, but first I have to
understand the backend interface for this. There are also other things
which can be improved (look for FIXME in the code).

There may be two bugs in the server and gui. One is that currently every
update must be flushed immediately to the Drawable otherways windows can
stay empty (this slows things down considerably). This is probably caused
by the gui not flushing correctly after drawing. The other is that the
backend server does not notify the graphics part when a window is
destroyed so it has no chance to free data associated with the window. I
think the backend server interface to the graphics part should allow the
following things:

1. Let the graphics part access system specific window parameters (this
   is already implemented)
2. Provide a byte array (possibly a shared memory buffer) to render into
   (not yet implemented but would be useful for both gslib and art rendering)
3. Maybe allow the graphics part to completly take over handling of some
   events (already provided for Expose)

Additionally in all three cases the server should notify the graphics part
about window creation, destroy and changes in parameters to allow the
graphics part to track the window state and maintain associated data.
(For window creation and parameter change GSSetDevice is called, but it is
not clear which parameter changes to check besides size change.)

Greetings,
BALATON Zoltan