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

[Jeff Baumes]

A couple small proposed changes to the infovis classes are here:

https://github.com/jeffbaumes/vtk-modularization/commit/4b5ec17101283c4debb49be02892a3ad6623ee0b

 - Making Infovis/SQL part of IO/SQL.

 - Making IO/InfovisXML part of IO/Infovis.

 - Making Infovis/GeometryFilters part of Filters/General.

 - Changing name of Charts/Context2D to Rendering/Context2D.

Jeff

On Fri, Mar 11, 2011 at 4:05 PM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> I made quite a few changes, and think I have covered most points
> raised. I also did some work to get a vtkCommonCore module building.
> This required a few moves back to CommonCore, and I added comments
> with reasons why each move was required.
>
> This required the removal of several functions in vtkMath.h using
> vtkPolynomialSolversUnivariate.h. We could of course move that back in
> too. I still have some more work to do, but a local Linux build is
> working now. Thank you for all of the suggestions. I have been looking
> through all of the ITK modularization build code to re-use, and will
> be working on that.
>
> https://github.com/cryos/vtk-modularization/blob/master/manifest.txt
>
> I think we have more consistency now. I have a few pending moves from
> David Gobbi I have not yet applied (most of them are in).
>
> Marcus
>
> On Thu, Mar 10, 2011 at 7:51 PM, David Thompson <dcthomp at sandia.gov>
> wrote:
> >> ...
> >> 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
> >
> >
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>


-- 
Jeff Baumes, Ph.D.
Technical Lead, Kitware Inc.
(518) 881-4932
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20110314/7e325d4a/attachment.html>