[vtkusers] java's vtkPanel does too much

[Jeff Lee]

Hi Steve,
vtkPanel and vtkCanvas are just example code to show how things work, 
and are ok for basic interaction - the only real important things are 
how the native methods are exposed.  Because the native methods are 
mapped to vtkPanel (see Common/vtkJavaAwt.h), the base class needs to be 
vtkPanel.  That is your tie into the c++ world.  That being said, I 
would recommend overriding vtkPanel.java in your own build area - just 
make sure your package name is vtk/vtkPanel.java and then you can do 
whatever you want (make sure you retain the native methods).

If there are bugs in vtkCanvas, please submit a bug report, or post some 
sample code so we can see what's going on.

In the long run, we should probably provide a base class with only 
native methods which can then be extended, without the above tinkering.  
Probably call it vtkNativeHook or something obvious, then vtkPanel is a 
subclass.  This will require changes to the c++ code in vtkJavaAwt.h to 
change the mangled jni method signatures, but it is trivial.  
Sublcassing as you have suggested below will not work.
Regards,
-Jeff

Steve M. Robbins wrote:

>Hi,
>
>A question to fellow Java/VTK users.
>
>We're going to use VTK with our own handling for mouse and keyboard
>events.  However the base java Component -- vtkPanel -- registers
>mouse and keyboard listeners, which I find inconvenient.
>
>For playing with VTK, I resorted to deriving a "bare" vtk panel class:
>
>
>  public class vtkBarePanel extends vtkPanel
>  {
>      public vtkBarePanel()
>      {
>          removeMouseListener(this);
>          removeMouseMotionListener(this);
>          removeKeyListener(this);
>      }
>  }
>
>
>This strikes me as inverted: the base class should be bare, with a subclass
>that adds default mouse & keyboard handling.  Don't you agree?
>
>I'm prepared to submit a patch to fix this by introducing
>vtkBarePanel, moving the native methods there, and having vtkPanel
>derive from it.
>
>I'm mainly wondering about naming.  My preference would be that the
>compoment be called vtkCanvas, since it derives from an AWT Canvas.
>But that name's already taken for a subclass of vtkPanel that uses
>render window interactor!  Thus, I'm proposing vtkBarePanel as a
>compromise.  I'm open to suggestions.
>
>-Steve
>
>[Incidentally, I've played a /little/ bit with example code using
>render window interactor and find it is very easy to crash the JVM
>with a segfault in VTK code.  I stress that I haven't done too much
>playing, but I'm curious: are others out there using render window
>interactors with java?]
>
>_______________________________________________
>This is the private VTK discussion list. 
>Please keep messages on-topic. Check the FAQ at: http://www.vtk.org/Wiki/VTK_FAQ
>Follow this link to subscribe/unsubscribe:
>http://www.vtk.org/mailman/listinfo/vtkusers
>
>
>  
>