[vtk-developers] Re: vtkNovelty

[John Biddiscombe]

> We've had a lot of discussion about vtkWidgets and Dean brought it up 
> again recently. Its also on my mind.
>
> I think that separating GraphicObjects from Filters/Processes might be the 
> way to proceed regarding Surfaces etc.
>
> Cones/Spheres/Kleins/Mandlebrots....some are images, some polydata etc, 
> but all are generators in some sense
>
> vtkGraphicObjects
> vtkGenerators
> vtkShapes
> vtkShapeSources
> vtkSolids
> ?
>
> JB
>
>
> ----- Original Message ----- 
> From: "Andrew Maclean" <a.maclean at cas.edu.au>
> To: "'John Biddiscombe'" <biddisco at cscs.ch>; "'list-vtk-developers'" 
> <vtk-developers at public.kitware.com>
> Sent: Sunday, February 20, 2005 12:51 AM
> Subject: RE: [vtk-developers] Re: vtkNovelty
>
>
>> 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
>>
>>
>> _______________________________________________
>> vtk-developers mailing list
>> vtk-developers at vtk.org
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>