I think what he is saying is that GTK can not do it, using Windows, and last I experienced it can not do it on OS X either. In fact it fails in almost the exact same way you wrote (the GL window takes over the entire top level). This indeed may very well be due to the problems you mentioned, mainly that GTK only use native windows at the top level, and does not use ei a native button (but instead relies on its own implementation of a button).
If this is the case, and given that 3D widgetry is becoming more and more prominent in user requests. I think your point, and bug, should be given some priority. To be fare, GLExt is not part of GTK, but it should be. ALL major platforms are using GL to do more and more desktop rendering and IMHO GTK should have a native support at the drawable level. In reading some of the documentation on how Quartz NSOpenGLView is implemented, there is definitely something special about a GL window. I believe it has to do with the GPU needed direct access to the memory, and the ability of modern windowing systems to have multiple rendering pipelines that merge on screen. For example: "The OpenGL specification does not provide a windowing layer of its own. It relies on functions defined by Mac OS X to integrate OpenGL drawing with the windowing system. Your application creates a Mac OS X OpenGL rendering context and attaches a rendering target to it (known as a drawable object). The rendering context manages OpenGL state changes and objects created by calls to the OpenGL API. The drawable object is the final destination for OpenGL drawing commands and is typically associated with a Cocoa window or view." -- http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html In fact in OS X has NSOpenGLView (which is derived from NSView) which transparently takes care of this functionality (as GTKGLExt is suppose to do). But in playing around with drawing OpenGL off and on screen, trying to create a transparent / borderless 3d object on screen, there are marked differences between the two object. For example, you can NOT have a transparent NSOpenGLView, you have to draw off-screen, and copy with transparency set to the background color of the off-screen buffer. This clearly shows that the GLView is different than a standard NSView. That is you can set the transparency for an NSView window and draw to have only what you draw appear, in an NSOpenGLview the background is always cleared to black (it does not have access to the screen buffer). I know this does not solve the problem.... but perhaps it will light some fires :) > Date: Mon, 2 Aug 2010 16:31:58 +0100 > Subject: Re: GDK_NATIVE_WINDOWS not working under Windows > From: michael.goffi...@gmail.com > To: eba...@gmail.com > CC: gtk-devel-list@gnome.org > > On Mon, Aug 2, 2010 at 3:51 PM, Emmanuele Bassi <eba...@gmail.com> wrote: > >> > ... specifically: no, it's not possible in Window. > >> > >> Are you sure about that? > >> Quick trials with PyQt4 under Windows show no problem in > >> having regular widgets on top of the OpenGL widget. > > > > this is not a Qt development list, though; so, as hint for the future > > don't try to compare functionality. :-) > > I was just commenting your statement that it's not possible > under Windows. What I'm trying to achieve *is* possible, because > Qt can do it. I'm trying to figure out a way to achieve it with > GTK+-2.16 (it seems I'm stuck at that version for OpenGL > support under Windows). > > > I think GtkGLExt allows placing gtk+ widgets on top of the GL drawing > > surface; at least, I'm pretty sure I've seen that happen. > > I'll give it another try. I'd just love to see a working example :-) > > Michael; > _______________________________________________ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
