Changes to graphic context handling

[Fred Kiefer]

I am planing to implement some serious changes to NSGraphicsContext and
the way this class interacts with the rest of GNUstep and wanted to
publish this plans first, so you may comment on them.

Currently GNUstep uses mostly just one graphics context, the one set up
in NSApplication. Only for printing other graphics contexts get created.
The idea now is to let each window have its own graphics context. There
still would be the default graphics context owned by the NSApplication
and the ones for printing. In addition, we may even have graphics
contexts to draw into memory space.

Why do this? One reason is of course to follow the change that Apple has
done for OS 10.4. With our current setup we could not implement many of
the methods on the class NSGraphicsContext nor some on NSView. Another
reason is to get rid of the strange way we currently set up the gstate
of a window, but this is a rather private reason. :-)

The graphics context will be selected when ever a view does a lock
focus. When this has happened everything will be as before, the context
returned by GSCurrentContext() will be the one for the active window.
The difference will only be when no view has locked focus. Then a
default context will be returned by this function. This context will
mostly be used by events. Drawing on the default context should be
regarded as an error. This may be a difference to the current state,
where this drawing is silently ignored.

Now, what is the real benefit of this change? It will allow us to
implement drawing for PS, PDF and bitmap output more easily. Our current
PS solution works to a certain degree, but it is incompatible to MacOSX.

If nobody opposes this change, I will go ahead with it.

Cheers,
Fred