In order to work with individual render windows it is useful to know which render window is the currently active render window. Active means that this is the render window the user last clicked in.
An active render window is already known inside the multi widget editor but it is not propagated to other workbench parts. The active render window should be highlighted.
Description
Description
Revisions and Commits
Revisions and Commits
| rMITK MITK | |||
| Restricted Differential Revision | rMITK15955aa5ec8f Send active render window | ||
| Restricted Differential Revision | rMITK7033b69669d2 Send active render window | ||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T28578 [mxn multi widget] Optimization of the mxn multi widget | ||
| Resolved | kalali | T26492 [mxn multi widget] Send active render window |
Event Timeline
Comment Actions
The active render window inside the multi widget editor is only set if the layout is changed.
It needs to be set if the user interacts with the render window.
Comment Actions
The active render window can be selected using the render window manager but it is not possible to do it the other way around - clicking inside a render window does not activate this render window.
Comment Actions
This feature should have been merged into master with 70ff72dd6f36 resp. D212.
However, it is not working anymore, I guess this has something to do with b8b5dc64e48c. Just a quick guess, maybe @kislinsk can help.
Edit:
I also found this 8a6ed854d15b and I am not sure how these two are related.
Comment Actions
Debugging into e.g. QmitkRenderWindow::event(QEvent* e) or void QmitkStdMultiWidget::mousePressEvent(QMouseEvent* e) shows that the current sender cannot be retrieved.
Using auto sender = this->sender(); returns a nullptr.
I tested this also with 4baa3ceec4 (develop before Merge branch 'feature/T27461-VTK9' into develop (which contains b8b5dc64e48c)) and here the sender can be retrieved as [QmitkRenderWindowWidget] {m_WidgetName=stdmulti.widget1 m_Layout=0x00000232926dd2a0 {...}
However, this only works within the QmitkStdMultiWidget or the QmitkMxNMultiWidget. Debuging and retrieving the sender within QmitkRenderWindow::event(QEvent* e) still results in the sender being a nullptr.
Testing directly with f6da756d92be (with b8b5dc64e48c merged into develop) returns a nullptr again in all cases.
Comment Actions
I dug deeper into this:
Using the working develop branch (4baa3ceec4) results in return QVTKOpenGLWidget::event(e); being called (line 198 of QmitkRenderWindow.cpp). This leads to this->InteractorAdaptor->ProcessEvent(evt, this->RenderWindow->GetInteractor()); being called (line 610 of QVTKOpenGLWidget).
Debugging inside void QmitkStdMultiWidget::mousePressEvent(QMouseEvent* e) shows that the call is coming from void QmitkRenderWindowWidget::MouseEvent(QMouseEvent * _t1) (the moced signal-function for QmitkRenderWindowWidget::MouseEvent, which is connected inside the QmitkRenderWindowWidget as connect(m_RenderWindow, &QVTKOpenGLWidget::mouseEvent, this, &QmitkRenderWindowWidget::MouseEvent);
Using the none working branch results in results in return QVTKOpenGLNativeWidget::event(e); being called (line 212 of QmitkRenderWindow.cpp). This leads to this->RenderWindowAdapter->handleEvent(evt); being called (line 269 of QVTKOpenGLWidget).
Debugging inside void QmitkStdMultiWidget::mousePressEvent(QMouseEvent* e) shows that the call is coming from bool QmitkSafeNotify(A *app, QObject *receiver, QEvent *event) (with some external Qt-code in between). Inside the QmitkRenderWindowWidget the QmitkRenderWindowWidget::MouseEvent is connected as connect(m_RenderWindow, &QmitkRenderWindow::mouseEvent, this, &QmitkRenderWindowWidget::MouseEvent);.
QVTKOpenGLNativeWidget does not provide any signals on its own.
Comment Actions
Ok I don't really understand what the changes did and what to expect from the modified code. I just need to react on a mouse pressed event inside a render window. Currently I don't see how this is possible.
I tested building with QtCreator to debug into the Qt-code but that didn't help.
Basically one should just be able to use sender() to retrieve the sending QObject. However, the sender is always null.