I have a VTK derived data type, that (for a variety of reasons) breaks the VTK naming convention. For example, it looks something like this
class myType: public vtkImageData
{
... blah blah ..
}
now I also have VTK derived algorithms that use that data type, for example
class myAlgorithm: public vtkImageDataAlgorithm
{
... blah blah ...
myType* = GetOutput(){
return myType::SafeDownCast(this->GetOutputDataObject());
}
... blah blah ...
}
The classes myType and myAlgorithm compile with the VTK module system and work fine. However, the problem comes when I try to wrap them in python, where the GetOutput method is ignored. It looks like vtkWrapPython skips the GetOutput method because the return type does not start with “vtk”.
With old versions of VTK (<9), I handled this by having a custom hacked version of vtkWrapPython. However, I am wondering if there is now a better way using the module wrapping system?
I believe that classes not starting with vtk might be ignored somewhere. We could instead rely solely on the hierarchy information though. Could be remembering wrong too.
Years ago we wanted the use a different class name prefix for our VTK-based library but had to switch to “vtk” for the wrapper to work.
It could be nice if custom prefixes were usable, but overall it is not that bad that VTK style is enforced for VTK-based classes (including class name prefix).
The wrappers still require VTK classes to start with “vtk” in order to fully wrap. It’s something I can fix when I find time. Please submit a bug report, if it’s on my radar then I’ll get around to it eventually.
Thanks David/ Andreas/ Ben. From the discussion above it sounds like my short term options are either to hack the vtkWrapPython again or to use classes begining with vtk. Longer term, this would be good functinolaity to have (from a user perspective) even if there is just an option for the user to provide a list of prefixes for wrapping.