[vtkusers] vtk, wx, MacOSX

[Sander Niemeijer]

On maandag, feb 14, 2005, at 15:08 Europe/Amsterdam, Prabhu 
Ramachandran wrote:

>>>>>> "SN" == Sander Niemeijer <niemeijer at science-and-technology.nl> 
>>>>>> writes:
>
>     SN> The Gtk-1.2 build in combination with my own Python wxVTK
>     SN> class still gives me problems on Mac OS X and Linux if I leave
>     SN> threading enabled in Python/wxWidgets. Unless I disable
>>>
>>> With Debian Sarge, using wxPython-2.4.2.6 via the
>>> libwxgtk2.4-python package, I use wxPython and VTK-4.4 fairly
>>> regularly.  wxc.so links to libpthread so I'm guessing that
>>> wxPython is built with threads.  No problems.  This is even
>>> when I use wxPython and VTK interactively using IPython with
>>> the -wthread option.  This is with GTK-1.2 and with the
>>> wxVTKRenderWindowInteractor.py from 4.4.
>
>     SN> But are you using the 'AddObserver' functionality to catch
>     SN> 'UserEvent' events and use a Python function as observer?  If
>     SN> you don't use this, everything works fine, for sure. It is
>     SN> because of the broken observer functionality that we were
>     SN> forced to disable threads.
>
> I don't catch 'UserEvent' but rely on the event mechanism for the
> standard messages a *lot* (yes, with Python callbacks).  So yes, I do
> use observers but not for the 'UserEvent'.

Hmmm. Seems I was a bit hasty writing my answer. Probably one of the 
major factors causing this problem is of course that we are using our 
own C++ version of wxVTK now. I have to dig up some information about 
the exact problems that we saw. When we encountered the problem we 
didn't have a lot of time to analyse it, but it was at least a problem 
with sending VTK events, from a VTK class that was created in the C++ 
domain, through the VTK/Python binding to a Python function (at the 
time it looked like a bug in either VTK or Python). I will come back on 
this. Maybe somebody on the list can provide an answer to this problem.

>>> Hmm, using the Enthought enhanced Python build works perfectly
>>> for me under win32 + wxPython-2.4.x + VTK 4.4.
>
>     SN> The last time I checked, Enthought was still using VTK 4.2
>     SN> (see also http://www.enthought.com/downloads/downloads.htm).
>
> That is correct.  I am using a more recent version that was announced
> for testing on the scipy-dev list.  This ships with 4.4.  I believe a
> final release of this might be available sometime soon.
>
>     SN> And the Enthought guys also applied some patches of their own
>     SN> to that version of VTK (AFAIKR one was also related to the
>     SN> problem I mentioned).  And are you using VTK windows embedded
>     SN> in wxWidget windows/frames (i.e.  combined with menus,
>     SN> buttons, etc.)? And are you using an application that is able
>     SN> to display multiple wxVTK windows that can be closed in any
>     SN> order by the user?  These two facts are important if you want
>     SN> to reproduce the problem I mentioned.
>
> The first yes, the second I have to admit, I have not tried.  I.e. I
> do embed a VTK widget into a native wxWidget but I haven't added
> multiple widgets that I close arbitrarily.  I do know of some folks
> who do embed multiple VTK windows in their apps.  I don't think they
> close these windows in an arbitrary order though.

Just some additional information to make clear what we are actually 
doing with the wxVTK windows: Our application is a command-based 
scientific application (dedicated to analysing atmospheric science 
data) with similarities to MATLAB, IDL, SciPy, etc. We use VTK to show 
our 2D and 3D visualizations. Each time a user issues a 'plot' command 
a new window (a wxWidgets frame with menu, buttons and a single wxVTK 
widget) appears and these plot windows can be closed in arbitrary 
order. The problem seems to appear when closing a plot window that 
currently doesn't have the focus (or OpenGL focus). But I am not 
entirely sure this is the cause, since I haven't been able to reliably 
reproduce the problem yet.

Best regards,
Sander