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

[Marcus D. Hanwell]

Thanks Jeff, I merged these changes in. I also removed the old Windows
CE code from VTK (hadn't been built in years), and updated the
manifest to account for a few new files. I have a Linux build of the
Common/Core library, and hope to spend some time getting the modular
stuff up and running.

The suggestions have been very helpful. Watch this space as I get more
building I will put up a test modular VTK so that you can explore the
file layout, builds etc. After we have the modules building I will
look at the tests, and finally examples.

Marcus

On Mon, Mar 14, 2011 at 12:52 PM, Jeff Baumes <jeff.baumes at kitware.com> wrote:
> 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
>