Fri, Sep 3
Thu, Sep 2
Wed, Sep 1
Tue, Aug 31
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);
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.
Mon, Aug 30
This seemed to be introduced / not completely fixed with fbc49fc5c831. Fixed it by adding the QmitkRenderWindowWidget class name to explicitly define the border only for this class (as it was already partially done in the mentioned commit).
Thu, Aug 26
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.
If D538 is accepted, 146a8d8 needs to be considered and cherry-picked, too.