[vtkusers] wxVTKRenderWindowInteractor and wxPython 2.5.2.8

[Sander Niemeijer]

> I haven't looked at it in any detail so am just as clueless.  I will
> need to spend some time on it to figure out what is wrong.  I'd
> probably start with the smallest case that works and build on that.

Yesterday I tried to figure out what the actual change was that made it 
work in wxPython 2.4.2.4, but made it stop working with 2.5.2.8. I 
think I have found the problem.

It seems that wxPython is not just wrapping the wxWindow.GetHandle() 
function, but providing its own implementation (see the GetHandle() 
wrapping in wxPythonSrc-2.5.2.8/wxPython/src/_window.i which calls 
wxPyGetWinHandle() in wxPythonSrc-2.5.2.8/wxPython/src/helpers.cpp).

The implementation of the wxPyGetWinHandle() function seems to have 
been changed, such that it now returns the XWindow handle for 
'm_widget' instead of 'm_wxwindow'. My understanding of Gtk is that a 
wx window consists of one or more Gtk windows, with m_widget being some 
kind of container Gtk window and m_wxwindow the Gtk window that should 
be used for drawing. So with the new wxPython we are getting the wrong 
Gtk XWindow handle to do the drawing.

I'll post an e-mail on the wxPython mailinglist to ask why they made 
the changes they did and see if we can get it fixed somehow.

On a side note: Has anybody ever tried to get the 
wxVTKRenderWindowInteractor working for Mac? I saw that Mathieu has 
some C++ version of wxVTK on his website, that looks like it supports 
Mac (both Cocoa and Carbon) but only using a top-level window handle. 
Any reasons why sub-windows can't be supported (in our application the 
VTK window is inside a splitter window)? Or has this just not been 
tried yet?

Best regards,
Sander