[vtkusers] misleadingly configurable option (-rw, -iw, -iv) of tkwidgets

[HIRAKI Hideaki]

I found a mysteric behaviour of vtkTkRenderWidget, for example, 

vtkRenderWindow renWin
puts [renWin GetReferenceCount]
#--> 1
vtkTkRenderWidget .widget -rw renWin
puts [renWin GetReferenceCount]
#--> 2
vtkRenderWindow newWin
puts [newWin GetReferenceCount]
#--> 1
.widget configure -rw newWin
puts [newWin GetReferenceCount]
#--> 1 
###  it's not 2. why?
puts [.widget configure -rw]
#--> -rw rw RW {} newWin
puts [.widget GetRenderWindow]
#--> newWin


The commands [.widget GetRenderWindow] and [.widget configure -rw] say 
that the RenderWindow for the widget is now "newWin" but actually the 
pointer to RenderWindow has not changed, inferring from the source code 
vtkTkRenderWindow.cxx (in vtk release 3.1):

   662  // Creates a render window and forces Tk to use the window.
   663  static int
   664  vtkTkRenderWidget_MakeRenderWindow(struct vtkTkRenderWidget *self) 
   665  {
   666    Display *dpy;
   667    int new_flag;
   668    vtkXRenderWindow *renderWindow;
   669    
   670    if (self->RenderWindow)
   671      {
   672      return TCL_OK;
   673      }
   674    

Once a RenderWindow is assigned, self->RenderWindow will never be
NULL. Then vtkTkRenderWidget_MakeRenderWindow() returns TCL_OK without
working. Can the lines 670-673 above be deleted? If this check is
really required, I think, -rw should not be a configurable option. 

Please correct me if I'm missing something important or fix the
behavior of tkwidget. The lines shown is taken from code for unix, but
it seems alike in the windows part and in the other tkwidgets 
vtkTkImageViewerWidget and vtkTkImageWindowWidget. 

Regards,

---
Hideaki Hiraki <hhiraki at lab.nig.ac.jp>