Fix event vtkCommand::MouseMoveEvent in QVTKInteractorAdapter class.
Description
There is a class called QVTKInteractorAdapter
that acts as a bridge between QtQuick
and VTK
for interaction. Qt
has an event called QEvent::HoverMove
, which is triggered when the cursor moves inside a hover widget. This event corresponds to the vtkCommand::MouseMoveEvent
event in VTK.
But it is not implemented in QVTKInteractorAdapter::ProcessEvent
:
if (t == QEvent::MouseButtonPress || t == QEvent::MouseButtonRelease ||
t == QEvent::MouseButtonDblClick || t == QEvent::MouseMove)
{
// ...
}
As you can see, only the following types of events are handled:
- MouseButtonPress
- MouseButtonRelease
- MouseButtonDblClick
- MouseMove
But the HoverMove
event is not mentioned here. It is necessary to add processing logic for it.
Solution
I tried to fix it myself and that's what I got:
//...
if (t == QEvent::MouseButtonPress || t == QEvent::MouseButtonRelease ||
t == QEvent::MouseButtonDblClick || t == QEvent::MouseMove ||
t == QEvent::HoverMove) // <--- adding check here
{
QMouseEvent* e2 = static_cast<QMouseEvent*>(e);
// give interactor the event information
#if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
auto x = e2->x();
auto y = e2->y();
#else
auto x = e2->position().x();
auto y = e2->position().y();
#endif
iren->SetEventInformationFlipY(
static_cast<int>(x * this->DevicePixelRatio + DevicePixelRatioTolerance),
static_cast<int>(y * this->DevicePixelRatio + DevicePixelRatioTolerance),
(e2->modifiers() & Qt::ControlModifier) > 0 ? 1 : 0,
(e2->modifiers() & Qt::ShiftModifier) > 0 ? 1 : 0, 0,
e2->type() == QEvent::MouseButtonDblClick ? 1 : 0);
iren->SetAltKey((e2->modifiers() & Qt::AltModifier) > 0 ? 1 : 0);
if (t == QEvent::MouseMove || t == QEvent::HoverMove) // and here <--
{
iren->InvokeEvent(vtkCommand::MouseMoveEvent, e2);
}
//...
}
//...
Results
As a result, QtQuick
now works with mouse move events. For example, it fixes the interaction with vtkCameraOrientationWidget
, as VTK
now properly handles mouse hover events correctly.
Environment
This bug was discovered in VTK
9.2 and has not been resolved in the VTK
9.3 beta version. It is possible that this issue has been present in earlier versions as well, but I have only tested it with these two versions.