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

>> On Dec 9, 2013, at 1:33 PM, Tim Blechmann
>> <t...@klingt.org<mailto:t...@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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to