[vtkusers] java's vtkPanel does too much
jeff at cdnorthamerica.com
Fri Feb 25 08:57:12 EST 2005
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.
Steve M. Robbins wrote:
>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()
>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.
>[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:
More information about the vtkusers