Re: bundlelisation of the backend

[dejaeger]

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

ok, I'm moving everything in this way. I first did the other way
because it was very short to code. Now, I find that it is painfull: 
edit GSMethodTable.h, NSGraphicsContext.[mh], write inline functions
in NSGraphics, .......Pfffff.

RFM>         declare the class GSBackend

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

yes, probably. Because we can load a category that's define in a
bundle. It should work.

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

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

well, I have no opinion on this question. If nobody gives one, I will
put everything in NSGraphics.h.

RFM>         * Source/SharedX/screen.h: new file

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

RFM> Could have been added as methods ofXGContext in XGContext.m

yes. but the code won't be shared anymore with the dps backend. For
the moment, I leave them here. But now, they are method of a
category of XGContext.