XML descriptions of VTK classes

Approximately three years ago, I started a project at Queen’s University to generate XML descriptions of all of the VTK classes. This project was part of the larger SimVTK project for generating Simulink wrappers for VTK (see previous post). The first version of vtkXML was written by myself and one of the Queens' undergrad compsci students and produced XML output that was really only useful for SimVTK and not useful for anything else.

Finally, I have given vtkXML a life of its own. This new version provides a comprehensive description of all class methods and documentation for each method. It essentially does two things: it provides a dump of all the information the VTK's lex/yacc wrapper front end can glean from the header files, and it synthesizes that information to give an overview of all class instance variables. A full description is provided here.

My pipe dream for vtkXML is for it to become part of a specialized VTK debugger that can inspect and modify VTK pipelines at runtime. There are python based pipeline inspectors, but none (as far as I know) that are pure C++. The idea is that the debugger can attach to a VTK process at runtime and get access to all VTK objects e.g. via the garbage collection system. In the immediate future, however, vtkXML will just be used to enhance SimVTK.


Update May 2nd, 2010: I've renamed this project to WrapVTK and pushed it out to github.

SimVTK release 0.2.3

Another alpha release of SimVTK is ready, and can be downloaded from the SimVTK site at Queen’s University. SimVTK is a visual programming environment for VTK inside of Matlab’s Simulink. This release adds support for Mac OS X.

I had my work cut out for me in getting VTK to work inside Matlab on OS X. Matlab uses four GUI toolkits (Java, Qt, Cocoa, and X11) and uses 24 independent threads. The Simulink thread (the one in which my VTK code is running) uses X11. But VTK is using Cocoa, and each Cocoa window that VTK creates responds to mouse/keyboard events from the main Matlab application thread. The result: every time I clicked in the window, VTK code would be called from the wrong thread. Boom. The solution was to write a "proxy" Cocoa window for VTK that queues the events, so that the Simulink/VTK thread doesn’t have deal with the events until it is good and ready.

SimVTK Partial Pipeline