It can be deleted without us knowing for MDI windows as happens in QtCurve config.
BUG: 376340
BUG: 379719
FIXED-IN: 5.12.7
davidedmundson |
Plasma |
It can be deleted without us knowing for MDI windows as happens in QtCurve config.
BUG: 376340
BUG: 379719
FIXED-IN: 5.12.7
Ideally we'd listen for the destruction of the QWindow and unregisterMenuBar which should avoid the wrong menu showing but this requires more elaborate reengineering. Also, this MDI stuff is quite funky, so I would say this a Qt bug since QDBusMenuBar came from Qt mostly unaltered
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
In reviewing I found a quirky bit of code:
void QDBusMenuBar::handleReparent(QWindow *newParentWindow) { if (newParentWindow && newParentWindow != m_window) { m_window = newParentWindow
if we ever got handleReparent with a nullptr, we wouldn't update our m_window. Could this be the root cause?
QPointer still needed. Could be refactored to also unregister on destruction but that requires storing the WId separately as in QObject::destroyed the ~QWindow already ran and as such winId() cannot be accessed