[Interest] QMacNativeWidget & memory management

deDietrich Gabriel Gabriel.deDietrich at digia.com
Tue Dec 10 13:33:39 CET 2013


On Dec 10, 2013, at 12:17 PM, Tim Blechmann <tim at klingt.org> wrote:

>> 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 in-between.

QMacNativeWidget creates an NSView that you will insert in your view hierarchy. That NSView will receive mouse and keyboard events, like any other view, that will be forwarded to the QMacNativeWidget as Qt events. Other events, such as expose or update events, will be also forwarded to Qt since they come form the NSView hierarchy update mechanism. However, the NSView, and hence Qt, will not receive NSWindow notifications, such as minimization, fullscreen mode, etc. (it does in pure Qt because we manage both the NSView and its NSWindow). And, obviously, pure Cocoa events and notifications need to be forwarded to Qt as well. We admit the documentation could be a bit more complete in this area.

> 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?

Yes, that’s the most straightforward solution. Adding a “nsViewDestroyed()” signal to QMacWidget is an option we should consider for some future version.

Best regards,

Dr. Gabriel de Dietrich
Senior Software Developer
qt.digia.com



More information about the Interest mailing list