[vtk-developers] VTK Widgets redesign
Will Schroeder
will.schroeder at kitware.com
Wed Aug 31 06:21:58 EDT 2005
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 Im 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>
More information about the vtk-developers
mailing list