[vtk-developers] Re: vtkNovelty

Andrew Maclean a.maclean at cas.edu.au
Sat Feb 19 18:51:25 EST 2005


Actually I was thinking about this also. I don't really think they begin in
Common.

Firstly a bit of history: 
All the vtkParametric*() functions were originally in Graphics but then the
surfaces were moved to Filtering, where they broke the VC6.0 build, so they
were moved to Common. The thinking regarding putting these functions in
Filtering was that the other sources (ths implicit ones) like Sphere and
SuperQuadric etc are there. However vtkSphereSource is in Graphics. So there
are inconsistencies as to where these functions live.

So we have a group of surfaces that are really sources scattered through at
least three different directories. Oh... I forgot vtkEarthSource in Hybrid.

We also have, on a slightly different tack, the Widgets, I think we will see
a lot of new widgets in VTK. At present these are in Hybrid. Should these
appear in a new top-level directory too? 

The whole aim of directories is to present the files in an ordered and
logical fashion. I think VTK does this very well and I also think that time
has proven that the initial directory structure was the correct choice.
However as VTK evolves new functionality appears that will not match the
directory structure. So we face a dichotomy in that existing directories may
not reflect the new functionality, but if we add new top level directories
we end up with too many, often with confusing names. So proceeding with
caution is a good idea. But I DO think GUISupport is a good idea.

Sorry for the long-winded ramble but I am getting to the point... :)

1) I think the implicit sources, parametric sources and other ones that
actually generate a surface should be in a separate directory. It can't be
called Sources because Sources to me would also include the data readers (in
keeping with the pipeline paradigm) and I think that these properly begin in
IO. Would it be too controversial to call this directory Surfaces and move
all the surface generators to it (including splines)? Or would a better name
be GeometricSurfaces? The name has to be picked carefully to convey that
these are surfaces like spheres etc. that are completely rendered. E.g.
vtkPlaneSource should be here but not vtkPlane (because it does plane
computations).
2) Widgets - I feel that we will run into the same problem with these. So
perhaps we should create a specific Widgets directory.
3) If 1) & 2) happen I feel that the remaining functions in Hybrid could
perhaps be subsumed into the other directories and Hybrid will vanish.

I don't think I have violated my comments above, in that, while proposing
the creation of two new directories, I have also proposed the abolition of
one!


Andrew


-----Original Message-----
From: vtk-developers-bounces at vtk.org [mailto:vtk-developers-bounces at vtk.org]
On Behalf Of John Biddiscombe
Sent: Saturday, 19 February 2005 12:06
To: list-vtk-developers
Subject: [vtk-developers] Re: vtkNovelty

[Apologies for multiple posts, having trouble with my email today.]


> http://public.kitware.com/pipermail/vtk-developers/2002-May/001580.html
>
> I suggested vtkNovelty as a place for less used code. I was only half 
> serious at the time, but I'm a little worried about the appearance of 
> classes like Klein and Mobius etc in vtkCommon.
>
> I'm glad these classes are in, but I don't believe vtkCommon is the place 
> to put them.
>
> Isn't it time we had a new top level directory for objects which are 
> useful, but specialized - like vtkHybrid, but with less dependencies?
>
> vtkSources would be a good name, if Source wasn't already used everywhere.
>
> JB
>


_______________________________________________
vtk-developers mailing list
vtk-developers at vtk.org
http://www.vtk.org/mailman/listinfo/vtk-developers





More information about the vtk-developers mailing list