This class enable VTK to render to
and interact with wxWidgets (formerly wxWindows)
just
as any wxWidgets component.
wxVTKRenderWindowInteractor provide a VTK widget for wxWidgets. This
class was completely rewritten to have the Look & Feel of the python
version.
MSW, X11, GTK (2.x is now the default one) and Mac (Carbon
require VTK5, and Cocoa was never fully working as of wx 2.6.2) (For
now Motif port is not fully working - testers required);
VTK 3.1, 3.2, 4.0, 4.2, 4.4, 5.0, 5.2, CVS;
wxWidgets 2.2.9, 2.3.1, 2.4.0 (buggy under linux), 2.4.1(still
buggy under linux), 2.4.2 (seems ok), 2.6.x (seems ok), 2.8.x (seems ok);
wxWidgets reparenting is enable with VTK 4.3 and upper;
Mouse wheel is available since VTK 4.4.
Caveats
Mouse Capture: Solved !
See problem description here.
And the magic --sync ...
There is a know bug that prevent this class to works for more info see
WX_USE_X_CAPTURE. This bug only affect wxGTK from 2.3.2 to wxGTK 2.4.0.
(For wxPython this correspond to wxPython 2.3.2 to 2.4.0.7 included).
See also History, 2) This is be fixed by now (in wxGTK 2.4.1 and upper)
Flickering issues/and : Solved !
Reported by Prabhu Ramachandran see his
thread.
In wxGTK 2.3.1 and before if you didn't use wxGLCanvas you'll end up
with a lot ok flickering that's why this class is templated over
wxGLCanvas.
You can avoid this effect by playing with WX_BASE_CLASS at your risk.
See wxGLCanvas/Scrollbars drawback (*).
I have been told that this bug desepear in XFree86 4.3 but had no
chance to try it myself...
(*) Scrollbars:
Furthermore this class is tempated over either wxWindows or wxGLCanvas,
in wxWidgets 2.3.1 and earlier, the wxGLCanvas had scroll bars.
To compile use the CMakeLists.txt (CMake).
Or for VTK 3.2 and older the Sample comes with a Makefile
that you need to edit by hand (see oldbin directory in archive)!
Changes
1.3 (1 June 2008)
wxVTK requires CMake 2.6 now.
1.2 (31 January 2007)
wxVTK requires CMake 2.4.5 now. This should solve the issue for bug #1611004,
Support wxGTK 2.8.0. wxGTK will now use wxWindow in wxGTK 2.8.0
and above. Thus you do not need to compile with opengl support anymore
now,
Fix compilation on wxX11 (Thanks to David Akers for report & patch).
1.1 (29 January 2007)
wxVTK requires CMake 2.4.4 now,
Partial patch to support wxGTK 2.8.0 (thanks to Philip
Schuchardt for report). But this is still not supported as they removed
the empty default cstor: [wxGLCanvas: empty (default) constructor],
Added wheel mouse support (Thanks to Philip Schuchardt for patch),
Fix compilation on non-GTK (Thanks to Reinhold Füreder for report & patch).
Apply patch from Alexander Nip to fix the 'BadWindow (invalid Window parameter)'
Some other minor fixes, I lost track of them, sorry :-P
0.8 (22 March 2005)
Carbon version declared working ! (Not all examples due to VTK-Carbon limitations)
MSW: Fix resize problem (Thanks to patch from John Norris)
A few cleanup in the code (use vtkTestUtilities instead of hardcoded paths)
0.7 (12 September 2003)
Initial start of Mac support ! A very big thank to Stefan Csomor !
I was able to reproduce this
bug. So please read the README
file first. It -should- contains all necessary informations.
I have also added some more examples. I was once reported the
vtkImageViewer/vtkImageViewer2 could not be used. So I added some
examples on how to use it.
0.6 (9 July 2003)
wxWidgets 2.4.1
is out, it should solve the problem with WX_USE_X_CAPTURE. Thus
wxWidgets 2.4.0 is officially declared unsupported. wxVTKRWI should
still work but not in the near future (versions not supported are wxGTK
from 2.3.2 up to 2.4.0). Again you
can't capture the mouse with wxGTK 2.3.2 to wxGTK 2.4.0 otherwise it'll
freeze your X session !
IMPORTANT note:
Even if this version (2.4.1) fixes a bug with mouse it introduced one
(at least under GTK). So you need to change src/gtk/timer.cpp 1.16.2.1
to timer.cpp 1.16.2.3. See my mail here.
And go to CVS here
to get it. So the recommended (=stable) wxGTK release is still 2.2.9
under Linux/GTK.
Remove all references to WX_BASE_CLASS, this is less readable but
I didn't find a good solution to deal with C++ RTTI stuff. Fixed.
-> To simplify I removed wxGLCanvas support for MSW (wxWindow seems
to be working in all case) and on the contrary wxWindow support for GTK
(wxWindow is not working in too many cases). If you still want to derive
from your specific class (e.g wxScrolledWindow) feel free to do it
yourself.
SplitSample now use wxCLIP_CHILDREN, this has been reported by
Nigel Nunn to reduce flickering on Windows. Flickering should
-hopefully- be solved this time.
Nigel Nunn also reported
a problem with destructor in Sample:
Also, commented out pRenderer->Delete(). This kills the process, but I get same problem with the MFC version. (Vtk: Dec 14 2002)
void MyFrame::DestroyVTK() { if (pRenderer != 0) { // pRenderer->Delete(); ! Note: skip this line } ... }
0.5
Some minor clean up,
Provide FindwxWindow.cmake & FindGTK.cmake since I am not
clear with the one provided with CMake 1.6.7 (this is transparent for
user and doesn't require any particular skill).
0.4
Memory leak fix.
0.3
Nicolas Clemeur reported some bugs when using GTK 2.x / and VTK
3.1: should be fixed now. He also reported this
bug with Exceed: not fixed.
Daniel Go has still some problems with the destructor and with
the OnSize event: Not fixed yet.
0.2
Charl Botha request that CaptureMouse was disable. See here.
This is now feasible with the method UseCaptureMouse(On/Off):
wxVTKRenderWindowInteractor *vtkRWI;
vtkRWI->UseCaptureMouseOn();
Beware that this methode will actually do something only if
WX_USE_X_CAPTURE was set to one. Meaning that all the tests for version
were successfull (or the user decided to override the tests, because he
hacks
down wxGTK !)
Daniel C Go reported some compilation problems with wxMSW. This
should be fixed.
0.1
First release.
Screenshots
History
Well first of,I hope this time the never ending story of wxVTK has
finally comes to
an end (as of 4/24/03) !
Flickering issues.
Many people experienced first this bad flickering issue. See here
and here.
WX_USE_X_CAPTURE.
Here are a couple of threads that I wanted to leave so people won't
have to reinvent the wheel:
Brian Todd reported
that wxVTKRenderWindow freezes at any resize
operation.
You can have a look at my posts first
one and second
one on the wx mailing list.
Here is the first
mail from Robert Roebling which I thought by that time would fix
everything. This was a tiny mouse typo, see here
for more info.
Then, here is the
mail from Owen Taylor that fixes the XFlush after grabing the mouse.
Mon Apr 21
15:07:29 2003 Owen Taylor <otaylor at redhat dot com>
* gdk/x11/gdkdisplay-x11.c (gdk_display_keyboard/pointer_ungrab):
Calling XFlush() after ungrabbing, to avoid problems if
the app subsequently blocks on a long-running operation.
(#106520,
reported by Rajkumar Siva)
Only the Linux version of Qt is available under GPL. To develop Qt
software under Windows, you must buy the Qt/Windows Professional kit
for $1550.00 per developer, even if you're developing free software.
Moreover you are forbidden from developing GPL software using the
Windows version of
Qt.
Thus, Qt really does not seem to be competitive with WxWindows for
multiplatform development, particularly if you're developing free
software.
Also some links from wxWidgets home site: wxWidgets Compared To Other Toolkits?
This class derive from wxWindow for MSW and from wxGLCanvas for
GTK...
wxGLCanvas : No mouse grab hack is needed with GTK 2.x . Beware,
wxGLCanvas is needed to handle GTK 2.x double buffering interfering
with the one from OpenGL
WX_USE_X_CAPTURE = // Keep capturing mouse after mouse is dragged
out of window
// (in wxGTK 2.3.2 there is a bug that keeps this from working,
// but it is only relevant in wxGTK if there are multiple windows)
