VTK/ARB/Meetings/August 2010: Difference between revisions

From KitwarePublic
< VTK‎ | ARB‎ | Meetings
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
* (Berk) Send information about XML C interface
* 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?
* (Berk) Ask for help from topic experts on how to organize the classes
* 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
* (Berk) Define some variables that make old targets work?
* '''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()
* Communicate using "remove legacy" flag to VTK community to test whether their code will work in VTK 6.0.
* 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())?