::New();
callBackCommand->SetCallback( rendererCallback );
callBackCommand->SetClientData((void*)this);
_rendererMainScene->AddObserver( vtkCommand::AnyEvent , callBackCommand ); // mp_ren is the vtkRenderer object.
// adjusts view so everything fits in the screen
_rendererMainScene->ResetCamera();
// add the VTK widget the layout
ui->frmViewer->layout()->addWidget(_vtkwidget);
```
Maybe this helps to pinpoint the problem with your code.
Anything amiss with how the objects are wired you’ll end up with the mouse events not going to where they are supposed to.
---
### Author:  [@Paulo\_Carvalho](https://discourse.vtk.org/u/Paulo_Carvalho)
#### Post date: [November 18, 2021, 9:55pm UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/10 "2021-11-18T21:55:10Z")
`SetParentRenderer()` is supposed to wire everything for you, that is, to send mouse events to the target renderer so whenever you manipulate the `vtkCameraOrientationWidget`, the scene updates accordingly. Maybe the problem is on how two renderers coexist in the same render window. See the code I posted above on how two renderers can coexist so the can both display things and receive user input events through the same window.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [December 6, 2021, 3:08pm UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/11 "2021-12-06T15:08:01Z")
Hi Cam,
I am the author of `vtkCameraOrientationWidget` and it’s representation. I’ll be honest, I haven’t tested it in a QtQuick window yet. As a matter of fact I have never done any QtQuick development besides the basics in QtCreator.
Could you help me by answering these questions?
1. When you try to rotate the camera interactively in the main renderer (the viewport with your dataset (s)), does the camera rotate like usual?
2. When you do the above, does the widget also rotate and does it show some sort of synchronization with the main renderer’s camera?
3. When you move mouse on top of the widget, do you see any of these visual changes in the widget?
a. A transparent greyish disk enclosing the widget
b. The color of the text (x or y or z) on the hovered grabber changes from black to white
I want to know if the widget is at least hot. Basically, for any interaction, it needs to get activated by hovering, which makes it hot.
It would be great if you could call Print on the widget and the interactor on any mouse click, move, release events. I would like to see the event flow.
---
### Author:  [@Cameron](https://discourse.vtk.org/u/Cameron)
#### Post date: [December 6, 2021, 8:04pm UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/12 "2021-12-06T20:04:02Z")
Hi jaswantp,
Thanks for your reply.
1. Yes, the camera rotates like usual in my main renderer.
2. The camera in vtkCameraOrientationWidget is synchronized with the main renderer.
3. I don’t see any kind of change. The widget is not hot. It doesn’t receive any mouse events including the mouse hovering.
I think the problem comes from QtQuick wrapper layer ([VTK/GUISupport/QtQuick at master · Kitware/VTK · GitHub](https://github.com/Kitware/VTK/tree/master/GUISupport/QtQuick)).
One thing I would look out for is in [QQuickVTKRenderWindow.cxx](https://github.com/Kitware/VTK/blob/master/GUISupport/QtQuick/QQuickVTKRenderWindow.cxx), on line 129 ~ 132, it creates a dummy renderer in `m_renderWindow` and sets the number of layers to 2, which could mess up with the renderer which renders vtkCameraOrientationWidget .
The other thing is [QQuickVTKInteractiveWidget.cxx](https://github.com/Kitware/VTK/blob/master/GUISupport/QtQuick/QQuickVTKInteractiveWidget.cxx) where sync function is defined.
I have no intention to change the source. I am kind of switching my main application back to QtWidget. I realized that I can inject QML element into my main QtWidget application.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [December 7, 2021, 1:14pm UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/13 "2021-12-07T13:14:07Z")
> and sets the number of layers to 2, which could mess up with the renderer which renders vtkCameraOrientationWidget .
Hmm, I think there is no need to worry about this because I safely preserve/increase the number of layers. See [83 - 84](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Interaction/Widgets/vtkCameraOrientationWidget.cxx#L83) and [100 - 101](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Interaction/Widgets/vtkCameraOrientationWidget.cxx#L100)
I’ve seen this widget work in ParaView which already uses 2 layers (base layer +1 for the older pvAxes orientation widget) so it should not be an issue with layers afaik.
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [December 7, 2021, 1:26pm UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/14 "2021-12-07T13:26:16Z")
This comment notes that the dummy renderer spans the entire viewport. [QQuickVTKRenderWindow.cxx:127](https://github.com/Kitware/VTK/blob/master/GUISupport/QtQuick/QQuickVTKRenderWindow.cxx#L127)
I assume because both the renderers `QQuickVTKRenderWindow::m_dummyRenderer` and `vtkCameraOrientationWidget::DefaultRenderer` live in the same layer and one overlaps the other, the events are not propagated to my widget. I have to investigate this…
In ParaView, it might have worked because the old pvAxes orientation widget occupied a smaller viewport rectangle and did not overlap the widget renderer’s viewport.
---
### Author:  [@kertalit](https://discourse.vtk.org/u/kertalit)
#### Post date: [August 16, 2023, 7:17am UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/15 "2023-08-16T07:17:11Z")
Hi! I have the same problem. As a result, did you manage to accurately understand the problem and is it being solved?
---
### Author:  [@jaswantp](https://discourse.vtk.org/u/jaswantp)
#### Post date: [August 17, 2023, 1:45pm UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/16 "2023-08-17T13:45:20Z")
Sorry, this is not being worked on at the moment. But I plan to look into it in my downtime.
---
### Author:  [@KevinWang-kk](https://discourse.vtk.org/u/KevinWang-kk)
#### Post date: [March 23, 2026, 8:54am UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/17 "2026-03-23T08:54:21Z")
* * *
Hello，I ran into the exact same issue with VTK events not firing properly in QML, so I dug into VTK’s official docs and source code to understand why—and how to fix it. Here’s a clear breakdown:
### Why VTK Events Act “Passive” in QML
VTK’s official docs for `QQuickVTKItem` (VTK 9.0+) confirm the core issue:
> VTK’s native event loop (`vtkRenderWindowInteractor::Start()`) conflicts with Qt’s event loop. All VTK events (mouse/timer/keyboard) are processed **passively** during QtQuick’s render cycle—not actively polled by VTK itself.
This is intentional (not a bug) for three key reasons:
1. **Thread safety** : VTK’s OpenGL context is bound to QtQuick’s render thread (separate from the GUI thread); active VTK event loops cause crashes.
2. **Performance** : QtQuick uses “On-Demand Rendering” (only renders when needed); passive event processing avoids wasted CPU.
3. **Cross-platform support** : Reusing Qt’s event forwarding works across Windows/macOS/Linux/Android/iOS.
### Direct Proof from VTK’s Official Code/Docs
#### 1. VTK Source Code Comment (GUISupport/QtQuick/QQuickVTKItem.h)
VTK explicitly states:
```cpp
/**
* \note VTK events (including timer events) are processed only when QtQuick triggers a render pass (e.g., `updatePaintNode`).
* VTK does NOT run its own event loop in QML.
*/
virtual vtkUserData initializeVTK(vtkRenderWindow* renderWindow);
```
#### 2. VTK’s Official Guidance
The [QtQuick Integration docs](https://docs.vtk.org/en/latest/guisupport/qtquick/index.html) highlight:
- **Limitation** : Calling `vtkRenderWindowInteractor::Start()` creates a separate window and blocks QML.
- **Fix** : Force QtQuick to render continuously to trigger VTK’s `ProcessEvents()`.
### My Solution (Validated to Fix Passive VTK Events)
To make VTK events (e.g., timers) fire reliably (no mouse input required), I added a QML `Timer` to force constant refreshes of `QQuickVTKItem`:
```qml
// Force QtQuick to render at 60 FPS (16ms interval)
Timer {
id: repeatTimer
interval: 16 // Milliseconds (60 FPS)
repeat: true
running: true
onTriggered: {
vtkitem.update() // Trigger VTK render cycle → process pending events
}
}
```
---
### Author:  [@KevinWang-kk](https://discourse.vtk.org/u/KevinWang-kk)
#### Post date: [March 23, 2026, 9:03am UTC](https://discourse.vtk.org/t/no-interaction-for-vtkcameraorientationwidget-in-qtquick/7161/18 "2026-03-23T09:03:26Z")
### Qt Event Forwarding → Simulating “Event Listening” in VTK’s Event Loop
`QQuickVTKItem::event` serves as the core entry point: Qt captures all input events (mouse/keyboard/touch, etc.) and forwards them to the VTK interactor via `dispatch_async`:
cpp
```auto
// Core logic of QQuickVTKItem::event
bool QQuickVTKItem::event(QEvent* ev)
{
// 1. Clone the Qt event (e.g., mouse move, key press)
auto e = ev->clone();
// 2. Add the event forwarding task to the async queue
dispatch_async([d, e](vtkRenderWindow* vtkWindow, vtkUserData) mutable {
// 3. Critical step: Convert Qt event → VTK event (via adapter)
d->qt2vtkInteractorAdapter.ProcessEvent(e, vtkWindow->GetInteractor());
delete e;
});
ev->accept();
return true;
}
```
`QQuickVTKInteractorAdapter::ProcessEvent`: Converts Qt events (e.g., `QMouseEvent`) into VTK events (e.g., `vtkCommand::MouseMoveEvent`) and invokes `InvokeEvent` on the VTK interactor.This step replaces the “listen for and process input events” functionality of VTK’s native event loop.
#### Supplementary Notes (Critical Context)
1. **Event Cloning** : Qt events are cloned before forwarding to avoid race conditions—since `dispatch_async` executes the task in the QML render thread (separate from the GUI thread where the original event lives).
2. **Adapter Role** : `QQuickVTKInteractorAdapter` is a VTK-provided utility that maps Qt’s event types/coordinates to VTK’s event system (e.g., Qt’s `Qt::LeftButtonPress` → VTK’s `vtkCommand::LeftButtonPressEvent`).
3. **Async Execution** : Forwarding via `dispatch_async` ensures VTK event processing happens in the QML render thread (where VTK’s OpenGL context resides), preventing cross-thread crashes.