A couple small proposed changes to the infovis classes are here:<div><br></div><div><a href="https://github.com/jeffbaumes/vtk-modularization/commit/4b5ec17101283c4debb49be02892a3ad6623ee0b">https://github.com/jeffbaumes/vtk-modularization/commit/4b5ec17101283c4debb49be02892a3ad6623ee0b</a></div>
<div><div><br></div><div> - Making Infovis/SQL part of IO/SQL.</div><div><br></div><div> - Making IO/InfovisXML part of IO/Infovis.</div><div><br></div><div> - Making Infovis/GeometryFilters part of Filters/General.</div>
<div><br></div><div> - Changing name of Charts/Context2D to Rendering/Context2D.</div></div><div><br></div><div>Jeff<br><br><div class="gmail_quote">On Fri, Mar 11, 2011 at 4:05 PM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I made quite a few changes, and think I have covered most points<br>
raised. I also did some work to get a vtkCommonCore module building.<br>
This required a few moves back to CommonCore, and I added comments<br>
with reasons why each move was required.<br>
<br>
This required the removal of several functions in vtkMath.h using<br>
vtkPolynomialSolversUnivariate.h. We could of course move that back in<br>
too. I still have some more work to do, but a local Linux build is<br>
working now. Thank you for all of the suggestions. I have been looking<br>
through all of the ITK modularization build code to re-use, and will<br>
be working on that.<br>
<div class="im"><br>
<a href="https://github.com/cryos/vtk-modularization/blob/master/manifest.txt" target="_blank">https://github.com/cryos/vtk-modularization/blob/master/manifest.txt</a><br>
<br>
</div>I think we have more consistency now. I have a few pending moves from<br>
David Gobbi I have not yet applied (most of them are in).<br>
<font color="#888888"><br>
Marcus<br>
</font><div><div></div><div class="h5"><br>
On Thu, Mar 10, 2011 at 7:51 PM, David Thompson <<a href="mailto:dcthomp@sandia.gov">dcthomp@sandia.gov</a>> wrote:<br>
>> ...<br>
>> Basic doesn't seem to fit, but perhaps a Core/Common would be a better<br>
>> name?<br>
><br>
> How about Common/Core? Common is familiar and those libraries really are<br>
> common dependencies. That way there can be Filtering/Core instead of<br>
> Filtering/Common which would be confusing for existing VTK developers.<br>
><br>
>>> 2. Filtering/Filtering is not descriptive. How about Filtering/General or<br>
>>> Filtering/Misc?<br>
>><br>
>> Yes, I think would be good. It is perhaps best to avoid repeating the<br>
>> same name twice in any of the kit names.<br>
><br>
> I agree.<br>
><br>
>> Would Filtering/General be reasonably descriptive.<br>
><br>
> I think so. They are general-purpose filters that aren't part of a<br>
> functional group of filters. Although you might be able to break some out,<br>
> there generally aren't enough classes to justify a separate library. For<br>
> instance, you could have Filters/Multiblock for filters that aggregate or<br>
> extract multiblock datasets. Those tend to get used together frequently. In<br>
> fact, one thing that surprised me about the mapping is how little it<br>
> segregates things by the data representation, given that many applications<br>
> will stick to using just one or two (e.g., the statistics filters use<br>
> multiblock and table datasets, but not polydata, image data, unstructured<br>
> grids, etc.). I guess there are enough filters that just operate on dataset<br>
> attributes (scalars/vectors/...) that it doesn't make sense, but I'm curious<br>
> whether you considered splitting Core/DataModel into Core/{GridModel<br>
> (regular sampling on a grid), MeshModel (unstructured), GraphModel, etc.}?<br>
><br>
>> I would like to avoid Misc if possible as much<br>
>> as possible, but that may also be a good one to use.<br>
><br>
> I agree that Misc should be avoided when possible.<br>
><br>
>>> 4. You said all the kits would be in a 2-deep hierarchy, but several<br>
>>> appear<br>
>>> at the top layer: AMR, TextAnalysis, Geovis. Should those be AMR/Core,<br>
>>> TextAnalysis/Core, Geovis/Core?<br>
>><br>
>> Yes, that could be a good starting point for a name. I was hoping<br>
>> those with better knowledge of those kits might come forward and tell<br>
>> me when the ideal organization would be there.<br>
><br>
> For Geovis you could split out the core functionality from the<br>
> view+representation classes. The whole library is pretty closely tied to<br>
> rendering, so I don't see a point in trying to separate out rendering code<br>
> from Core, but this:<br>
><br>
> [Geovis/Views]<br>
> Geovis/vtkGeoView.h<br>
> Geovis/vtkGeoView.cxx<br>
> Geovis/vtkGeoView2D.h<br>
> Geovis/vtkGeoView2D.cxx<br>
> Geovis/vtkGeoAlignedImageRepresentation.h<br>
> Geovis/vtkGeoAlignedImageRepresentation.cxx<br>
><br>
> [Geovis/Core]<br>
> everything else<br>
><br>
> would keep Geovis/Core independent of Views/Core.<br>
><br>
>        David<br>
><br>
><br>
><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jeff Baumes, Ph.D.<br>Technical Lead, Kitware Inc.<br>(518) 881-4932<br>
</div>