Re: The big divide - graphics contexts and window servers

[Nicola Pero]

> I'd like to propose a reasonably radical change in the GNUstep backend 
> structure. While thinking about how to implement better graphic 
> rendering in GNUstep I realized that the current backend structure is 
> not very clean. Currently it consists of functions that handle windows 
> and events (which rarely change, at least on a single platform) and 
> functions that handle graphics (of which there are numerous libraries 
> available, even for the same platform). I think we should split these 
> up, into say, a GSWindowServer object, which handles display(window) and 
> event issues, and the current NSGraphicsContext, which just handles drawing.
> 
> This is better, not only conceptually: NSGraphicsContext is really meant 
> to handle drawing into a specific device (window, printer, etc), but 
> also in reality: Most libraries handle graphics only, not window 
> creation, etc. It also separates things that the normal developer can 
> mess with (creating contexts, drawing into them), from things that are 
> better handled through the AppKit interface (creating windows, handling 
> events).

Yes - it looks like a good idea to me in general.

I think we want to make the interface front-end to back-end very cleanly
designed and simple ... the Windows backend should also be an occasion to
make the interface cleaner and simpler.

We can also probably drop most DPSwindow functions (or whatever the name),
or just define them in the gui (for backward compatibility only - but
likely nobody is using them, so we can just drop them) as wrappers around
calls to the GSWindowServer object.

It's important to define a single interface (in the example, not both
DPSwindow functions and GSWindowServer, but only one of the two; the other
one should be implemented in term of the other one in the gui, so that the
backend only needs to implement the one which is actually required)
between frontend and backend, and document it.