[vtk-developers] VTK Widgets redesign

[Will Schroeder]

John-

I appreciate your feedback. Let me address these issues that you have raised.

At 07:00 PM 8/29/2005, John Platt wrote:
>Below are some minor issues I have had at 
>various time with widgets. I was wondering how the new proposals may help.
>
>1. Handle geometry – can the 3D handles be made 
>to remain a fixed size, independent of any 
>camera zooming? It would also be nice if they could snap to points.

Yes, we can do this and I have modified the 
vtkHandleWIdget (and related representations) to 
respond to the renderer's StartEvent to resize the handles each render.

As far as "snap"; I just added a PlacePointEvent 
into VTK. I am using this event to move points 
after placement. Alternatively, the interaction 
events can be intercepted and used to move points 
to a grid. IMHO this is an application specific 
feature and does not belong in the widgets directly.

>
>2. Widget conflicts – I use several scalar bar 
>actors/widgets and suffer from them being placed 
>on top of each other because I’m too lazy to 
>check the position! Typically, you just want 
>these widgets not to obscure your view or each 
>other. Maybe there is a case for a class of 
>widget that just ‘transports’ certain 
>actors/info around the render window. Some 
>simple spatial management functions could then be defined.

There is no such class (yet). As I mention in the 
document, there is a need for some "mediation" or 
"negotiation" classes which could do what you propose. So this is on the list.

>
>3. Custom widgets - how easy will it be to build 
>custom widgets using existing widgets as 
>composites? For example, suppose I want a ruler 
>widget consisting of 2 cone handles, a line 
>connecting the handles and a text box to 
>continuously display the distance between the 
>cones. All the individual components are built but can they easily be combined?

This is being done now and it seems to work okay. 
There are some conflicts related to changing 
cursors when you have many widgets contending for 
control of the cursor. I will address this at some level in the near future.

>
>4. Single use widget – widgets for making some 
>form of 1-off selection might typically enable 
>on mouse button down, select on mouse move and 
>disable on mouse button up. Presumably the 
>customised event binding will allow this type of configuration.

This can be done now by careful use of 
command/observer callbacks. To some extent this 
is application specific. I am adding a measuring 
widget now that has some of these features.

>
>5. Is there any provision to confine the widgets to the render window?

Interesting question. I have looked at Maya's 
very simple yet powerful widgets. They have 
decided to keep widgets a constant size with 
respect to the window so it's harder to move the 
widget out of the window. (Of course, if a widget 
is attached to a position in space and the camera 
moves such that the position is no longer visible 
by the camera then you are not going to see the 
widget.) Widgets presented in display coordinates 
(like text, captions, etc.) of course never go out of the window.

Will 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20050831/d9f21393/attachment.html>