[vtk-developers] VTK modularization: initial pass at new modules

[David Thompson]

> ...
> Basic doesn't seem to fit, but perhaps a Core/Common would be a  
> better name?

How about Common/Core? Common is familiar and those libraries really  
are common dependencies. That way there can be Filtering/Core instead  
of Filtering/Common which would be confusing for existing VTK  
developers.

>> 2. Filtering/Filtering is not descriptive. How about Filtering/ 
>> General or
>> Filtering/Misc?
>
> Yes, I think would be good. It is perhaps best to avoid repeating the
> same name twice in any of the kit names.

I agree.

> Would Filtering/General be reasonably descriptive.

I think so. They are general-purpose filters that aren't part of a  
functional group of filters. Although you might be able to break some  
out, there generally aren't enough classes to justify a separate  
library. For instance, you could have Filters/Multiblock for filters  
that aggregate or extract multiblock datasets. Those tend to get used  
together frequently. In fact, one thing that surprised me about the  
mapping is how little it segregates things by the data representation,  
given that many applications will stick to using just one or two  
(e.g., the statistics filters use multiblock and table datasets, but  
not polydata, image data, unstructured grids, etc.). I guess there are  
enough filters that just operate on dataset attributes (scalars/ 
vectors/...) that it doesn't make sense, but I'm curious whether you  
considered splitting Core/DataModel into Core/{GridModel (regular  
sampling on a grid), MeshModel (unstructured), GraphModel, etc.}?

> I would like to avoid Misc if possible as much
> as possible, but that may also be a good one to use.

I agree that Misc should be avoided when possible.

>> 4. You said all the kits would be in a 2-deep hierarchy, but  
>> several appear
>> at the top layer: AMR, TextAnalysis, Geovis. Should those be AMR/ 
>> Core,
>> TextAnalysis/Core, Geovis/Core?
>
> Yes, that could be a good starting point for a name. I was hoping
> those with better knowledge of those kits might come forward and tell
> me when the ideal organization would be there.

For Geovis you could split out the core functionality from the view 
+representation classes. The whole library is pretty closely tied to  
rendering, so I don't see a point in trying to separate out rendering  
code from Core, but this:

[Geovis/Views]
Geovis/vtkGeoView.h
Geovis/vtkGeoView.cxx
Geovis/vtkGeoView2D.h
Geovis/vtkGeoView2D.cxx
Geovis/vtkGeoAlignedImageRepresentation.h
Geovis/vtkGeoAlignedImageRepresentation.cxx

[Geovis/Core]
everything else

would keep Geovis/Core independent of Views/Core.

	David