[vtk-developers] vtkGenericRenderWindowInteractor

[Prabhu Ramachandran]

>>>>> "DG" == David Gobbi <dgobbi at irus.rri.ca> writes:

    >> widgets.  I think backwards compatibility is important and see
    >> no reason to break it for the Python widgets.  David, what do
    >> you think?

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

We could indicate that the old widget will not be supported in the
future.

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

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

The backwards compatibility problems are small I admit but here are a
few points.

  (1) The older widgets had the methods UpdateRenderer, Reset,
  Surface, Wireframe etc.  It is possible that some code out there
  uses these methods.  I personally use UpdateRenderer when I
  initialize a vtkTkRenderWidget in order to setup the
  _CurrentRenderer attribute correctly.  While changing code that uses
  these methods is no big deal it is an issue when you have users who
  use the code with different versions of VTK.  The only way around
  this would be for the application writer to create try blocks that
  allow the code to work for multiple versions.  This can be painful.

  (2) It is not straight forward to change the interaction behaviour
  from a scripting language.  You need to create a new
  InteractorStyle.  While it allows for nice delegation it is not as
  direct as writing your own widget with exactly what interactions you
  want.

  (3) The default behaviour of the interactor based widgets would be
  joystick while the older widgets are all Trackball like.  This might
  be a little confusing to users who expect the trackball behaviour.
  Minor point, I admit.

  (4) Handling 'KeyPress' events is a little tricky.  I dislike the
  'w' and 's' keybindings.  With the interactor based widget it is not
  enough if I simply unbind the w and s keys.  This is because any
  keypress is bound to KeyPressEvent.  What you have to do is unbind
  all the keypress events and then bind only those keys that you want.
  This is not nice.  It is possible to create another Interactor style
  that does the job but is circuitous.  I might be mistaken and it
  might be very easy to change the behaviour via the
  vtkInteractorStyle but I haven't been able to find such an easy way
  to do this.


That said, the interactor based widgets are definitely very nice and
powerful.  Its just that breaking compatbility produces a few problems
that could be avoided by keeping the old widgets.

prabhu