[vtk-developers] VTK Widgets redesign

[dean.inglis at camris.ca]

Widgeteers,


Action/Event binding - the changeable action/event binding with key modifiers was a nice
add on by SB for vtkImagePlaneWidget and I had thought of extending that design
to all the other classes, but abstracting this functionality away from a class/by/class
implementation is way better.  

I'm not sure why, but should this paradigm be more generalized,
as in vtkEventTranslator?  

Centralizing AddEventsToInteractor/RemoveObserver also means 
all widgets can now be visible but not necessarily interactive and again centralizes code
currently implemented as InteractiveOn/Off in some but not all widgets.

Decouple Event Processing from widget geometry - like it alot and I agree with
the mandatory API.  GetInteractionState could also be very useful publicly when 
a) a widget needs to know what another widget is doing (in a callback scenario)
b) GUI updates
I like that there are now handle widgets with 2D and 3D subclasses.

Issues 

What should the names of the widget events be? It you look at vtkWidgetEvents.h you will see one 
possibility. In general naming things is always an issue.

I think once a few old widgets are refactored this will be clarified...


Mediating widget conflicts - this seems like an opportunity for a widget in and of 
itself like vtkMultiWidgetManagerWidget or some such thing. Hashing out a widget
like this would likely expose weaknesses in the proposed design.


Capturing the API between a widget and its representation. How to document this? 
Is there a more general API? 
SetRepresentation(rep) assumes that rep is type vtkWidgetRepresentation*. However, this means 
current widgets that roughly follow the separation of widget/representation 
(e.g., vtkScalarBarWidget) but have a method like SetScalarBarActor() take a particular 
actor or other type of vtkProp*, and not a representation. The question is: do we need 
a vtkWidgetRepresentation class? In my experience yes, since without it the corresponding 
widget is too intimate with the representation. For example, if you look at the current 
implementation of vtkScalarBarWidget it is clear that the widget assumes way too much 
about the API, making it hard to use this widget for anything but a vtkScalarBarActor. 
IMHO a good design for a widget and its representation(s) should abstract the API between 
them as much as possible so its easy to add new representations. 

I always thought vtkXYPlotWidget and vtkScalarBarActor (and recently vtkOrientationMarkerWidget)
shared a ton of code.  This may mean that some pre-widget vtk classes are due for 
a better inheritance/desing strategy.


I will spend some time when I can converting my widget classes over to the
proposed design to get a better handle on the issues.  I could also contribute
to documenting the design/change over etc.  I compiled the tar'd 
classes, ran the tests, found some minor bugs but it looks great so far.
Thanks for all your hard work on this. 


Dean