Re: bundlelisation of the backend

[Richard Frith-Macdonald]

On Sunday, March 25, 2001, at 05:34 AM, address@hidden wrote:

>  
> I finished a first working implementation. It was very short to write 
> in fact. the patches in the archive are for the current version of 
> gui/xgps. For now, it does'nt work with xdps. But I will do it after. 
>  
> If you want the backend to be a module, define BACKEND_BUNDLE=yes (in 
> a shell, for instance). Then compile and install gui and 
> xgps. Otherwise, xgps will be compile as a library (as before). 
> Anyway, both gui and xgps need to be recompile after the patch is 
> applied. xdps is now broken. 
>  
> The design is not very good. The interface between frontend and 
> backend should be better defined. Maybe we should have a structure of 
> functions ? 
>  
> I try to describe exactly what I did. Feel free to ask any question or 
> make any comment. 

Some points from your README -

        * Source/NSApplication.m: define the pointers thar are declared in
        AppKit/GSBackend.h.

I think that the function pointers should go in GSMethodTable.h along
with the rest of the backend interface.  I also think that it makes
more sense to have the concrete implementations of the functions be
methods of NSGraphicsContext ... since almost all of them use the
current context anyway, so having them use 'self' is easy.  Also it
makes more sense to have them as methods of this class, again so that
all the backend interaction uses the same mechanism.

        * Source/GNUmakefile (libgnustep-gui_HEADER_FILES): add GSBackend.h

I don't think the GSBackend.h file should be necessary.

        * Headers/AppKit/NSGraphics.h: remove all the declarations that
        correspond to fonctions that are defined in the backend. Include
        AppKit/GSBackend.h instead.

Definately wrong ...we expect to find the functions declared in this file,
so we need them there for macOS-X compatibility.
This file should be modified to contain inline functions to indirect off the
pointers in the GSMethodTable ... like the ones in PSOperators.h


        * Headers/AppKit/GSBackend.h: new file. Declares as pointer to
        functions all the functions from the backend that are needed in the
        frontend :
        NSEraseRect, NSHighlightRect, NSRectClip, NSRectClipList,
        NSRectFill, NSRectFillList, NSRectFillListWithGrays, NSDrawButton,
        NSDrawGrayBezel, NSDrawGroove, NSDrawTiledRects, NSDrawWhiteBezel,
        NSDottedFrameRect, NSFrameRect, NSFrameRectWithWidth, NSReadPixel,
        NSCopyBitmapFromGState, NSCopyBits, NSDrawBitmap, NSBeep,
        GSWDefineAsUserObj, GSWViewIsFlipped, GSWindowDepthForScreen,
        GSAvailableDepthsForScreen.

Most of those functions must be declared in NSGraphics.h

        declare the class GSBackend

I'm not sure about this ... couldn't NSGraphicsContext perform this job?

        * Headers/AppKit/GSWraps.h: remove all the declaration. Include
        AppKit/GSBackend.h instead.

I think the two functions in GSWraps.h should be inline functions indirecting 
off
the table. I guess they could stay where they are or be added to NSGraphics.

        * Source/SharedX/screen.h: new file

        * Source/SharedX/screen.m (_GSWindowDepthForScreen): put an
        underscore in front of the name.
        (_GSAvailableDepthsForScreen): same.

Could have been added as methods ofXGContext in XGContext.m



In summary ... I think that all the basic principles are fine, but ...
1. Removing functions from NSGraphics.h is absolutely wrong.
2. Using the lookup table (GSMethodTable) for everything is the way
to go, rather than creating a load of new, globally scoped, function
pointers.  It would be safer (avoid global variables), more consistent,
and would localise all frontend-backend interaction in the graphics
context.

I believe quite strongly in localising and minimising the set of
frontend-backend interactions required.  Ideally, in the long run I'd
like to be able to write instructions for putting together a new
backend that can say that *everything* is done via the graphics
context (this would also go a long way towards helping us move to
a threaded architecture at some point in the future ... a separate
graphics context in each thread).