VTK/ARB/Meetings/August 2010: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
== Agenda == | == Agenda == | ||
http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility | |||
http://www.vtk.org/Wiki/VTK/Modularization_Proposal | |||
== Notes == | == Notes == | ||
| Line 8: | Line 10: | ||
* People need to link to a different set of libraries | * People need to link to a different set of libraries | ||
* Kit boundaries are bound by subclasses | * Kit boundaries are bound by subclasses | ||
* VTK has a "fat" hierarchy tree | ** This is not much of an issue since VTK has a "fat" hierarchy tree | ||
* Within common, there are things that are not too common | * Within common, there are things that are not too common | ||
** Implicit functions, math, etc. | ** Implicit functions, math, etc. | ||
| Line 14: | Line 16: | ||
* What dependencies do the examples have? | * 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 | * Potentially make XML readers / writers in own kit so people could work with VTK file format without much VTK | ||
* Look at what ITK does with Rippl this coming year | * Look at what ITK does with Rippl this coming year | ||
* Possibly use namespaces? | * Possibly use namespaces? | ||
* Move some informatics stuff into Titan as part of the reorganization | * 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 | * Look into "shopping cart" approach for the future where you create custom libraries based on individual class needs | ||
* Remove unnecessary dependencies among kits | * Remove unnecessary dependencies among kits | ||
* | * '''Consensus: This will be a good thing, let's do it.''' | ||
Removing 4.0 compatibility layer | Removing 4.0 compatibility layer | ||
| Line 31: | Line 31: | ||
* Make a script that checks for these errors. | * Make a script that checks for these errors. | ||
* Flagging errors in next release when people are connecting pipelines using SetInput() | * Flagging errors in next release when people are connecting pipelines using SetInput() | ||
* | * Should 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 | * Make sure "key" toolkits are ready and notified of upcoming changes | ||
** Slicer | ** Slicer | ||
| Line 39: | Line 39: | ||
** Titan | ** Titan | ||
** others? | ** others? | ||
* '''Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.''' | |||
== Action Items == | == Action Items == | ||
* (Berk) Send information about XML C interface to ARB | |||
* (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community | |||
* (Berk) Look into defining some variables that make old targets work | |||
* (Kitware) Do modularization of kits | |||
* (Kitware) Remove 4.0 legacy code | |||
== Some Other Time == | == Some Other Time == | ||
* Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())? | * Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())? | ||
Revision as of 20:36, 17 August 2010
Agenda
http://www.vtk.org/Wiki/VTK/Remove_VTK_4_Compatibility http://www.vtk.org/Wiki/VTK/Modularization_Proposal
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
- This is not much of an issue since 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
- Look at what ITK does with Rippl this coming year
- Possibly use namespaces?
- 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
- Consensus: This will be a good thing, let's do it.
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()
- Should 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?
- Consensus: Remove compatibility layer, leave SetInput() but change behavior in 6.0.
Action Items
- (Berk) Send information about XML C interface to ARB
- (Berk) Ask for help from topic experts on how to organize the classes, present ideas to VTK community
- (Berk) Look into defining some variables that make old targets work
- (Kitware) Do modularization of kits
- (Kitware) Remove 4.0 legacy code
Some Other Time
- Change to static vtkAlgorithm::Connect(a->GetOutputPort(), b->GetInputPort())?
