i'm thinking this might be possible if we create the x window stuff currently
in XGXSubWindow in the NSOpenGLContext and then on -setView: call
XReparentWindow, instead of delaying until we have a parent to create the
the -openGLContextWithShareContext: method here does this...
The current GNUstep implementation allows only 'windowed context' (defined
with [-setView]). 'Off screen' and 'fullscreen' contexts will be implemented
sooner or later, and dont need any view or sub-window.
I dont know many about shared contexts. They look te be handled fine in
Could you please post some code that should work but does not ? Thanks!
Incidentally I found a small bug in XGGLFormat. But this has nothing to do
with your problem :/
You cannot 'makeCurrent' a context that has not been attached to a drawable,
ie with [-setView:]. This is not a bug. You probably can not do that even with
If your renderer needs a drawable or a context to initialize itself, then you
have to wait for the View to be ready. I'm afraid you can not even create
programmatically your GLView, then re-parent it when your nib window is ready,
because the current implementation destroys the context when the view is moved
to an other window (this is new, not tested and may not be Cocoa-compatible)
Some suggestions :
* You may insert your NIB file in a programmatically created window that
contains a GLView. (dunno how to do that!)
* Split your NIB file : 1st load the GLView part, then initialize your
renderer, then load the remaining NIB.
* If you can change the context of your renderer _after_ initialization, you
may initialize it with a dummy context.
here's a hack of a patch which implements this, works with my test & MyGL and
my program, it'll need lots cleaning up
Yeah, i know we need a drawable, but the drawable and the NSView are
relatively unrelated except they must share a display.
the views window must be the contexts parent to be displayed in the right
place, we can create the drawable before we are attached to an NSView and then
reparent it to get the view to draw in the right place...
theres a few ways to work around this, create the windows offscreen on
this doesn't help me really, because one of the problems i've run into is
that things like NSOutlineView call -reloadData in initWithCoder: which makes
writing my dataSources a pain since I have to write checks in every method to
see if openGL has been initialized yet, because a call to the renderer before
it is initialized will crash it,
the other option is using multiple nib files, this involves creating an NSBox
and replacing those for every view which shares a window with my nib, besides
that I can't actually look at what my window will look like.
and I cannot change the context after initialization.
I really don't think that there is any proof that the test attached to this
bug shouldn't work, and it isn't documented as not working, and this patch
should show that it isn't impossible.... anyhow yes, I know it could be worked
around but none of those options really appeal to me
(and fwiw I don't really care if it isn't portable because hacking the
renderer to use glxGetCurrentContext isn't portable either).
You can not create a sub-window in [GLView -initWithFormat...] because you
don't even know if the context will draw to a window. It might draw
fullscreen, or to a pixmap, or to a pixel buffer. You can not know before
[-setView:] or [-setFullscreen], etc.
But you can reparent a NSOpenGLView. As i said, the current (partial and not
tested) implementation destroy the glx context, that will be re-create on the
new window by the next [-openGLContext]. This (simple) behavior might be
Please check the attached patches to the current trunk version. You should
then be able to reparent an NSOpenGLView without the context to be destroyed.
1. create the view [-initWithFrame:...] in an unmap or hidden window
2a. get the context and initialize your renderer
2b. load your nib file
3. add the view to your brand new window [-addSubview:]
I've just tested Matt's contextTest v1 and v2 on Mac OSX 10.4:
* V1 does not output any message, but this does not mean it does something.
An extended test might help.
* V2 is (almost) ok : I think my patch might be port to Win32 and added to
the official backend, as it's a improvement in compatibility.
Matt : did you test my patch along with my suggestions in your project ?