[Interest] QMacNativeWidget & memory management

[Tim Blechmann]

> On Dec 9, 2013, at 1:33 PM, Tim Blechmann
> <tim at klingt.org<mailto:tim at klingt.org>> wrote:
> 
> trying to embed a Qt widget hierarchy into a Cocoa hierarchy, i'm 
> currently trying to figure out how the memory management is supposed
> to work:
> 
> i've adapted the example [1] to add a RedWidget to the layout. it
> gets allocated in the applicationDidFinishLaunching method, but for
> some reason it is never destroyed. so i wonder, is this a bug or a
> feature? or more generally speaking: will the QMacNativeWidget
> automatically be destroyed when its parent NSView* is destroyed? if
> not, what is the preferred way to make sure that it is destroyed
> correctly?
> 
> While the QMacNativeWidget’s underlying NSView will be destroyed by
> Cocoa when its parent view is, that NSView does NOT take ownership of
> any QWidget (Note that you should not cache the NSView pointer unless
> you’re sure about its lifespan. Furthermore, calling
> “QMacNativeWidget::nativeView()” will create a new NSView if it has
> already been deleted). Therefore, you should delete the
> QMacNativeWidget yourself. In the example, since we create the
> QMavNativeWidget in “applicationDidFinishLaunching:”, the right place
> to deallocate it would be “applicationWillTerminate:”. In this
> regard, the example is incomplete and should be fixed.

i see.
there is one further point that i'm a bit confused with: according to
the QMacNativeWidget documentation, the user has to take care of
delivering events from Cocoa to the QMacNativeWidget. however it seems
that this is actually done internally, because in the example the qt
widgets react on mouse/keyboard events without additional code inbetween.

therefore i wonder: which events are propagated to the nsview and which
are not? and is there a way to get a notification when the parent NSView
is destroyed or do i need to subclass NSView which owns the
QMacNativeWidget and destroys it on dealloc?

thanks,
tim