Re: Suggestion for improving backend configuration...

[Ivan Vučica]

A partially related thought.

If there is thinking of actually restructuring code to minimize work people 
have to do (anything more than what Greg proposed), it may be a good idea 
perhaps to somehow further separate window creation and drawing code. Last time 
I looked at -back for purposes of UIKit, it seemed tightly dependent on -gui, 
and UIKit could use cross-platform window creation code. Drawing is not 
important to it, as long as Core Animation can easily (and cross platform) get 
an OpenGL context to paint into. Everything is painted by Opal and Core 
Animation anyway, and runloop is handled by it as well.

So if anyone more intimately familiar with -gui and -back internals is willing 
to look at this, it'd be of great service for any future UIKit implementation.

As it stands now, it may be easier to depend on both -gui and -back, but I'm 
uneasy with pulling in everything just to get NSWindow and NSOpenGLContext (or 
for OpenGL ES, an internal -back class XGXSubwindow). The alternative is 
somewhat more appealing, but also more work: using just Xlib, GLX/EGL and 
NSRunLoop.

Regards,

Ivan Vučica
via phone

On 28. 6. 2012., at 09:34, Richard Frith-Macdonald <address@hidden> wrote:

> 
> On 28 Jun 2012, at 02:55, Gregory Casamento wrote:
> 
>> Fred,
>> 
>> What I had thought is that the initializeBackend method could use 
>> information from the info.plist for the bundle to determine what the 
>> concrete subclass for the context and server are.  This would be trivial to 
>> implement.   
>> 
>> It seems to me that it should be possible to compile a backend without 
>> modifying the logic I quoted in the previous message.
>> 
>> Wouldn't it be also better to build the common parts of the backend into a 
>> framework so that "third party" backends could be written without requiring 
>> direct changes to GNUstep code.
>> 
>> This is just something I was thinking about that could be useful which is 
>> why I asked for thoughts regarding it.  It is not a fully formed idea, so 
>> there shouldn't be any puzzling over it, I was asking people to brainstorm a 
>> little with me.
> 
> I agree that it would be quite nice (in the sense that it feels more 
> elegant/pleasing) to have the backend class determined automatically without 
> having to set a user default.
> 
> Another option would be to remove the GSBackend.m source, and have it 
> generated automatically when you build a backend ... then the GSBackend 
> +initialize method would be different for each backend and would initialize 
> the correct classes.
> 
> We could also abolish all these separate names for the context class and just 
> use a single name (as I understand it, a backend bundle only contains one fo 
> the context classes anyway.
> 
> Or we could add a [GSBackend+contextClass] method to return the correct 
> context, and backend developers would just override that in a category.
> 
> That being said , as Fred points out, all this is *in* the backend source ... 
> so any third party writing a new backend can set it up any way they like 
> anyway and wouldn't be modifying any gnustep code (they'd be replacing the 
> gnustep backend code with their own).
> 
> Of course, you are also right that minimising the work people would need to 
> do is a good idea, but that probably means wholesale restructuring to try and 
> extract common functionality 
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev