<html>

<body>

John-<br><br>

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

raised.<br><br>

At 07:00 PM 8/29/2005, John Platt wrote:<br>

<blockquote type=cite class=cite cite=""><font size=2>Below are some

minor issues I have had at various time with widgets. I was wondering how

the new proposals may help.<br>

 <br>

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.</font></blockquote><br>

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.<br><br>

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.<br><br>

<blockquote type=cite class=cite cite=""><font size=2> <br>

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.</font></blockquote><br>

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.<br><br>

<blockquote type=cite class=cite cite=""><font size=2> <br>

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?</font></blockquote><br>

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.<br><br>

<blockquote type=cite class=cite cite=""><font size=2> <br>

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.</font></blockquote><br>

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.<br><br>

<blockquote type=cite class=cite cite=""><font size=2> <br>

5. Is there any provision to confine the widgets to the render

window?</font></blockquote><br>

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.<br><br>

<font size=2>Will</font></body>

</html>