GNOME Bugzilla – Bug 619430
NSView missing from sublevel widget's / containers
Last modified: 2016-04-10 16:24:49 UTC
Created attachment 161777 [details] [review] GtkGLExt patch for GTK+ OS X Quartz hack I've made a patch for GtkGLExt for the OS X Quartz port of gtk+/gdk. The problem was that when using GtkGLExt on a sublevel widget the OpenGL view would fill the entire toplevel window. What I found was that the previous implementation used a function: gdk_quartz_window_get_nsview(widget->window); that always return the NSView for the toplevel window and that no function is available that returns a NSView for a sublevel widget container. My approach is very hackish. I create a NSOpenGLView and add it as a subview to the toplevel NSView and then resize the NSOpenGLView manually when necessary. The attached patch must be applied after the previous GtkGLExt quartz patch.
(In reply to comment #0) > that always return the NSView for the toplevel window and that no function is > available > that returns a NSView for a sublevel widget container. There is only a single NSView per GDK toplevel window, it has been like that since the introduction of client side windows in GTK+ 2.18. There is no sub NSView for sublevel widget containers. On a related note, see bug 619155.
I guess then that the only thing to change in my patch is the way resizing is done?
Is there any update on this? We would like to build our app with the Quartz backend. We've got several sublevel gl widgets (editor view, 3d preview, texturebrowser) and the current code scales everything to fill the entire top level window.
nothing has changed. as kristian noted above, GTK/GDK does *not* create an NSView per widget. each widget just draws into the "toplevel" NSView in the right place. this is the entire definition, fundamentally, of "client-side windows", even though that concept really comes from X11.
thanks for the reply. But I'm wondering there must be an NSOpenGLView instantiated as the GL content cannot just be drawn into the top level NSView. So what is the solution then?
as the comments on the bug explain, GTK/GDK puts a single NSView into the NSWindow as the "content view". If you want to do more, you need to (a) retrieve the content view from the NSWindow using gdk_quartz_window_get_nsview() (b) pack your own NSView (or derived type) into that NSView (c) make sure that the content view is large enough to contain everything. however, you will not be able to mix-and-match the packing of GTK widgets and your NSView-derived views, other than in an extremely basic way: you can only "append" new NSViews to the display list within the content view. the heirarchy is as follows: NSWindow -> HAS-A -> NSView (Content View) -> HAS-ZERO-OR-MORE -> NSViews If the content view contains ONLY GTK widgets, it contains ZERO NSViews. If (as in ardour) you use Cocoa to pack additional nsviews (or derived types) into the content view, then you have be sure to position them correctly. the top level GTK widget (ignoring the GtkWindow that corresponds to the NSWindow) will be packed at upper left (0,0). You need to size it appropriately, and then follow it with an appropriately positioned additional NSView(s). See the linked other bug that kristian provided that has a lot of comments from me about how this works in ardour.
Sorry for the delay, and thanks for your reply. I'm by no means a GTK expert, but how come it works when buildings against the x11 backend just fine. Shouldn't this behavior be identical? And there are many people suffering from the same issue obviously: https://mail.gnome.org/archives/gtkglext-list/2010-March/msg00004.html
> Shouldn't this behavior be identical? Not really, since Quartz and X11 are two fundamentally different windowing systems. Also, GtkGLExt is 2.x only and no further change will happen on the GTK+ 2.x API.