# Upgrading VTK widgets framework

**URL:** https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455
**Category:** Development
**Created:** [June 11, 2026, 4:25pm UTC](https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455 "2026-06-11T16:25:30Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![jadh4v](https://discourse.vtk.org/user_avatar/discourse.vtk.org/jadh4v/32/4149_2.png) [@jadh4v](https://discourse.vtk.org/u/jadh4v)
#### Post date: [June 11, 2026, 4:25pm UTC](https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455/1 "2026-06-11T16:25:30Z")

</div>

As part of our future roadmap for VTK, we are planning to upgrade the VTK widgets framework to better support applications in managing and synchronizing widgets and their properties. This mainly includes synchronization of widgets and their corresponding representations across multiple viewports (vtkRenderer) and render windows (vtkRenderWindow). This is a very common use case for multi-view / multi-window applications that display widgets and annotations across multiple views. Current VTK widget classes are not designed to explicitly support this use case. As an extension of this effort, we also plan to introduce a higher level widget management structure to simplify the construction and management of widgets in an application.

**State synchronization for representing widgets across multiple views**

We plan to introduce a set of widget state classes (e.g. vtkLineWidgetState) that can be used to synchronize widget states across multiple views. Multiple widgets that wish to share state with each other will essentially point to the same state object as their model.

 ![image](https://discourse.vtk.org/uploads/default/original/2X/5/5754b7ef740b201ee3b56c74b61c6e95d26f6fbd.png)

**Simplifying widget instantiation and management**

Instantiating and adding specific widgets to a renderer often requires understanding multiple classes and how they interconnect, for example, knowing about the multiple 2D / 3D representations and corresponding widget classes. There are multiple widgets serving similar functionality such as vtkLineWidget, vtkLineWidget2, and vtkMultilineWidget. We plan to introduce a vtkWidgetManager class (similar to what is implemented in vtk-js: [https://kitware.github.io/vtk-js/docs/develop\_widget.html](https://kitware.github.io/vtk-js/docs/develop_widget.html)) that will manage the life cycle of a widget and support synchronization of properties. The vtkWidgetManager will support pre-built recipes for the common use cases for widgets to simplify this process of choosing which classes to instantiate and which representations to use for common use cases. The utility of the widget manager could be extended further to features such as setting the current “in-focus” widget that will grab all interaction events (similar to vtk-js).

We would like to receive ideas and suggestions from the community within the scope of the above mentioned task.

**References**

1. vtk-js widget concept: [https://kitware.github.io/vtk-js/docs/concepts\_widgets.html](https://kitware.github.io/vtk-js/docs/concepts_widgets.html)

2. vtk-js develop widgets: [https://kitware.github.io/vtk-js/docs/develop\_widget.html](https://kitware.github.io/vtk-js/docs/develop_widget.html)

3. Widget Manager Trame: [https://github.com/Kitware/trame-vtk/blob/master/examples/widgets/clip.py](https://github.com/Kitware/trame-vtk/blob/master/examples/widgets/clip.py)

---

<div class="post-metadata">

### Author: ![mwestphal](https://discourse.vtk.org/user_avatar/discourse.vtk.org/mwestphal/32/19_2.png) [@mwestphal](https://discourse.vtk.org/u/mwestphal)
#### Post date: [June 12, 2026, 6:08am UTC](https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455/2 "2026-06-12T06:08:42Z")

</div>

What matters as a maintainer:

1. Current design/classes keep working (even if deprecated)
2. New designed/classes are simpler to use, implement and maintain

The current design make the widget classes a bit hard to use and very hard to add new widgets and such, with tons of boilerplate.  
If the new design account for that, i’d be happy!

---

<div class="post-metadata">

### Author: ![amaclean](https://discourse.vtk.org/user_avatar/discourse.vtk.org/amaclean/32/224_2.png) [@amaclean](https://discourse.vtk.org/u/amaclean)
#### Post date: [June 13, 2026, 12:50am UTC](https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455/3 "2026-06-13T00:50:04Z")

</div>

Do look at the vtk Examples, in particular the [C++](https://examples.vtk.org/site/Cxx/) and [PythonicAPI](https://examples.vtk.org/site/PythonicAPI/) versions. The widgets are particularly useful in the sense that they can be rescaled, resized and moved. However as Mathieu said, thay are a bit hard to use, often requiring the setting of very many parameters for positioning etc.. To overcome this I have been implementing classes like **ScalarBarProperties** and functions like **make\_scalar\_bar\_widget** and specific functions like **position\_sbw\_h** and **position\_sbw\_v** that resize horizontal and vertical scalar bars, dependent upon the number of entries in categorical color series. Additionally there are functions like **get\_text\_positions** to simplify placing text widgets in a viewport. You can see all these in [!464](https://gitlab.kitware.com/vtk/vtk-examples/-/merge_requests/464) - not finished yet! Also look at [FroggieView](https://examples.vtk.org/site/PythonicAPI/Visualization/FroggieView/) where slider callbacks are used. The C++ interactive example now works.

Please also consider nice examples showcasing any new classes. They can be based on the VTK tests.

---

<div class="post-metadata">

### Author: ![LucasGandel](https://discourse.vtk.org/user_avatar/discourse.vtk.org/lucasgandel/32/1831_2.png) [@LucasGandel](https://discourse.vtk.org/u/LucasGandel)
#### Post date: [June 17, 2026, 9:03am UTC](https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455/4 "2026-06-17T09:03:50Z")

</div>

Widgets synchronization across viewports is indeed a nice feature to support. I’ve been using vtkWidgetSet to handle this so far, but it requires modifying VTK to address [this TODO](https://gitlab.kitware.com/vtk/vtk/-/blob/master/Interaction/Widgets/vtkWidgetSet.cxx?ref_type=heads#L46). Having similar flexibility with a simpler approach would be great.

---

<div class="post-metadata">

### Author: ![untereiner](https://discourse.vtk.org/user_avatar/discourse.vtk.org/untereiner/32/7561_2.png) [@untereiner](https://discourse.vtk.org/u/untereiner)
#### Post date: [June 19, 2026, 3:35pm UTC](https://discourse.vtk.org/t/upgrading-vtk-widgets-framework/16455/5 "2026-06-19T15:35:54Z")

</div>

Would it be possible to also separate the parts depending on QtGui and QtWidgets ? It would allow to reuse some behaviors with QML ? Question seems weird but [esri](https://github.com/Esri/arcgis-maps-sdk-toolkit-qt/blob/main/README.md) and [kdab](https://www.kdab.com/software-technologies/developer-tools/kddockwidgets/) did something similar. I think the key point is the createWidget function.
