[vtk-developers] vtkGenericRenderWindowInteractor

[David Gobbi]

On Mon, 15 Apr 2002, Prabhu Ramachandran wrote:

> >>>> "BH" == Bill Hoffman <bill.hoffman at kitware.com> writes:
>     BH> At 11:34 PM 4/12/2002 +0530, Prabhu Ramachandran wrote:
> 
>     >> I just got the the Python-Tkinter widget working
>     >> satisfactorily.  I am not going to change the existing classes
> [snip]
> 
>     BH> Sounds good, glad to here it is working.  I would say that we
>     BH> should break backwards compatibility.  It will be better to
>     BH> have only one type of interaction supported.  We could
>     BH> simulate the old one with a style couldn't we?
> 
> I disagree.  The older widgets have certain methods that folks might
> use.  I see no harm in having two different implementations of
> widgets.  That way if someone would like a customized widget they
> could learn how to do it by looking at the older widgets.  Also by
> breaking backwards compatibility we make it very hard for people who
> use specific features of the old widgets that have no sensible
> equivalents in the newer widgets.  I think backwards compatibility is
> important and see no reason to break it for the Python widgets.
> David, what do you think?

I'm kind of split on this, but I'm leaning towards breaking backwards
compatibility because 1) having two versions around means twice as
much maintenance and 2) I think the changes can be done with
close to full backwards compatibility.

The Tkinter and wxPython widget interaction was almost exactly the
same as Trackball interaction, wasn't it?  And the idea behind the
vtkGenericRenderWindowInteractor is that e.g. in each Tkinter event 
will be hooked into the interactor via a tk 'bind', so
it seems to me that the only real change to the vtkTkRenderWidget
is that instead of 'bind'ing the mouse to Python methods that move
the camera (as is done now), we will be 'bind'ing the tk mouse events
to the Interactor and the Interactor will move the camera.

People will be able to use a tk bind to override the interactor
behaviour, just as they can override the Python-code camera
interaction in the current vtkTkRenderWidget.