[vtkusers] wxVTKRenderWindowInteractor and wxPython 2.5.2.8

[Sander Niemeijer]

A small update:

> 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.

They were quite fast with providing an answer on the wxPython 
mailinglist. The result is that they changed it back to be more in line 
with the previous behavior (it's already in the CVS version of 
wxWidgets/wxPython).
I have given it a try and it seems to work again.

> 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?

I had a small e-mail discussion about this (off-list) with Mathieu and 
Yves and it seems that it might be possible to support (either or both) 
the Cocoa/Carbon interfaces of wxPython with 
wxVTKRenderWindowInteractor.py
I'll try to find some time the coming period to make a first go at 
implementing this (it will probably also require some small changes to 
the wxPython implementation of the GetHandle() function).

I'll post any progress back to the list.

Best regards,
Sander