VTK/ARB/Meetings/August 2010

Notes

Modularization

• Reorganize VTK, clean up dependencies
• Clean up build process, use newer CMake functionality
• Copy out some subdirectories into separate repository
• People need to link to a different set of libraries
• Kit boundaries are bound by subclasses
• VTK has a "fat" hierarchy tree
• Within common, there are things that are not too common
  • Implicit functions, math, etc.
• Make a graph of dependencies, perhaps do clustering
• What dependencies do the examples have?
• Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK
• (Berk) Send information about XML C interface
• Look at what ITK does with Rippl this coming year
• Possibly use namespaces?
• (Berk) Ask for help from topic experts on how to organize the classes
• Move some informatics stuff into Titan as part of the reorganization
• Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs
• Remove unnecessary dependencies among kits
• (Berk) Define some variables that make old targets work?

Removing 4.0 compatibility layer

• In VTK 4.0, left interdependencies between data objects and pipeline
• Main incompatibility is people using b->SetInput(a->GetOutput())
• Should we leave the SetInput() function?
  • Leaving it will produce a runtime error for the case above. It would also allow existing code to work.
  • Changing the name to SetInputDataObject() will produce a compile-time error.
• Make a script that checks for these errors.
• Flagging errors in next release when people are connecting pipelines using SetInput()
• Communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.
• Make sure "key" toolkits are ready and notified of upcoming changes
  • Slicer
  • ITK
  • ParaView
  • VisTrails
  • Titan
  • others?

Some Other Time

• Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?