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 _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
