[vtk-developers] HOW DO YOU ... aggregate vtk Widget

[kent williams]

This is very interesting to me and suggests how I can deal with
multiple contours as a group.

What I'm foggy on is how to handle interactions with multiple
contours. As it happens now, the default behavior of multiple contours
works pretty much as I'd like without my code explicitly managing
which is the currently active contour.  If I filter all event handling
through a parent widget, I have to do a 'catch and dispatch' thing
with every event, whereas now I just let VTK do it's thing.

On the other hand, knowing which contour is the 'active' contour would
be useful; a request I have is to color the currently edited contour
differently than others.

I am climbing a learning curve here, and hope I'm not asking too many
stupid questions!

On Thu, Apr 3, 2008 at 4:16 PM, Karthik Krishnan
<karthik.krishnan at kitware.com> wrote:
> Kent:
>
>  We do have a framework for "composite widgets". A few examples are
>  vtkParallelopipedWidget, vtkBiDimensionalWidget etc.
>  The bidim widget for isntance manages 4 handles internally as child
>  widgets to specify the end points.
>
>  The methods you want to be aware of are
>
>  1.   vtkAbstractWidget::SetParent( vtkAbstractWidget *parent )
>
>     This will cause the children to listen to the parent for
>  interactions. They will not listen to the renderwindow interactor.
>     This works well for you because you can decide exactly when to
>  invoke what event. For
>     instance, you could listen to the Control-LeftButtonPressEvent and
>  depending upon certain conditions,
>     invoke a LeftButtonPressEvent. This will cause fresh contour
>  points to be added only when Ctrl-Left is pressed
>     and your conditions are met as opposed to left.
>
>  2.   vtkAbstratWidget::SetPriority( .. )
>
>     Set the priority of the children slightly below that of the parent.
>
>  3. vtkEventCallbackCommand
>
>  Your parent can decide when to abort event processing, irrespective of
>  what the child says. In other words you can have something like
>  one click causing contour points to be added on more than one contour.
>
>
>  Hope this helps
>  --
>  karthik
>
>
>
>  On Thu, Apr 3, 2008 at 4:54 PM, kent williams <nkwmailinglists at gmail.com> wrote:
>  > I have an application that allow tracing of 3D features in volume
>  >  images -- in our specific case, anatomical features of the brain.
>  >
>  >  To do this I use multiple instances of vtkContourWidget.
>  >
>  >  vtkContourWidget wasn't really designed to be used this way, but it
>  >  behaves remarkably well.  My empirical observation of its behavior is
>  >  that for a give rendering window, if there are multiple instances in
>  >  the view, you can only add points to the currently open Contour.  If
>  >  all contours are closed, which contour catches interactions depends on
>  >  whose control points to which the mouse cursor.  So even if you add 10
>  >  contours you can add points to only one contour at a time.
>  >
>  >  In my initial work on the tracer, all the state information, event
>  >  handlers, etc are associated with my class that encapsulates the
>  >  viewer in which tracing occurs.
>  >
>  >  I want to separate all the multiple contour widget management into
>  >  it's own class, so that it can be instantied and used with any vtk
>  >  viewer.  My question is this:
>  >  The obvious 'vtk' way to do this would be to sublcass
>  >  vtkAbstractWidget, but this carries with it all sorts of baggage I
>  >  don't care for. What I want -- call it vtkMultiContourWidget has all
>  >  its constituent vtkContourWidget instances, so it doesn't need
>  >  everything that's in vtkAbstractWidget.   So where should this new
>  >  class fit in the VTK class hierarchy? Should I just derive it from
>  >  vtkObject and then do whatever internal management necessary myself,
>  >  or ...
>  >  _______________________________________________
>  >  vtk-developers mailing list
>  >  vtk-developers at vtk.org
>  >  http://www.vtk.org/mailman/listinfo/vtk-developers
>  >
>