[VTK ARB] VTK NIH Maintenance grant

[Andrew Maclean]

Sorry for the late reply.

Under the heading to expand or refactor:
Definitely modularisation, I would also think consideration of using
namespaces is also important. One other refactorisation we could
undertake is looking at groups of files to see if they are in the
appropriate places. For example vtkParametricFunctionSource is in
Graphics, but the parametric surfaces such as vtkParametricTorus are
in Common - my feeling is that they really should be in Graphics. This
was done years ago because there was some limitation in VS6 about the
number of files that could be processed to form a library.
As regard to namespaces, I think this will be inevitable in the
future. NOTE: I am NOT proposing renaming functions or classes, (I
like the current naming convention). But looking towards the future I
can see us inventing longer and longer names for classes of similar
functionality that could happily live in different namespaces. As an
example the recent e-mail about splitting
vtkSurfaceReconstructionFilter into two classes, to me implies a
vtk::SurfaceReconstruction namespace. Thus people who want to do
surface reconstruction know that these algorithms reside in this
namespace. We could have vtk::ImplicitFunction, vtk:ParametricFunction
namespaces etc... I feel this will substantially assist in
modularisation and documentation.

Of course there is a huge code base out there, but I wonder if an
automated script in python could also be developed as part of this
proposal to look at the source files and insert the appropriate
namespaces based on the include files to ease transition.

Regards
   Andrew


On Sat, Jul 31, 2010 at 2:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> My first interest is definitely in refactoring the VTK widgets, but it
> looks like it is already on the list.  Do you just want the ideas, or
> some sort of write-up?
>
>  David
>
>
> On Fri, Jul 30, 2010 at 9:45 AM, Will Schroeder
> <will.schroeder at kitware.com> wrote:
>> I am working with Brad Davis to put together a proposal for VTK-focused,
>> biomedical computing work (a so-called NIH maintenance
>> grant http://grants.nih.gov/grants/guide/pa-files/PAR-08-010.html). We'd like
>> to hear any ideas you might have, but be forewarned the number of specific
>> aims will be limited to 3-5, so most ideas I'm afraid won't make the final
>> cut. Nonetheless, any suggestions for VTK improvements that would benefit
>> biomedical computing are welcome. I've pasted a rough list that we've
>> collected thus far..
>> Will
>> --
>>
>> Process
>>
>> Tools and process for distributed community involvement/support/use of VTK
>>
>> Functionality to Expand or Refactor
>>
>> Widgets
>> GL 4? support (e.g., new mobile devices)
>> Expanded image support
>>
>> Non-contiguous, non-axis aligned
>> Expand itk/vtk connection support with good examples
>>
>> New Stuff
>>
>> Arbitrary precision geometry routines (casey)
>> Introspection layer (pat)
>>
>> Software Process Improvements
>>
>> Incorporate static analysis into nightly/weekly process
>>
>> Pure Maintenance
>>
>> Triage & Fix Bugs (see issue tracker)
>> Clean up build process (some funding already from Berk)
>>
>> Documentation & Outreach
>>
>> Improve number, scope, number of languages for examples
>> Support VTK users list
>> Courses?
>> Provide support for community members to contribute (e.g., provide grant to
>> cover a month of work)
> _______________________________________________
> Arb mailing list
> Arb at vtk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/arb
>



-- 
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________