[vtk-developers] Re-organization of vtk Tcl packages

[Blezek, Daniel J (CRD)]

Sebastien,

  This issue of Tcl packages will all go away when we all move to Python. 8)  Adding more granularity
to which vtk "kits" you use, allows processing without a X connection, something that is missing with
the current method of running vtk.  

> I'd have appreciated a more modern approach/syntax, namespace-based :
> 
> ::vtk
> ::vtk::base
> ::vtk::filtering
> etc.

  We haven't precluded namespaces, but packages don't allow this sort of flexibility.  Each
sub-package can have it's own namespace under ::vtk, but for the moment, I couldn't think of any code
to put under them.  So there is only ::vtk right now.

> You mean MakePackages.tcl ?
> 
> Well, we had a discussion about that privately, but I do not 
> see how it can 
> work. It just plain crash for Windows. Furthermore, how are 
> you going to 
> handle auto-refresh, as well as auto-initalization code 
> (stuff done for 
> vtkWin32RenderWindowInteractor for example) ?

  Actually, I was pleasantly surprised to see that any *.tcl scripts that have toplevel code in them,
are automatically sourced by "package require", thus the mechanism for vtkWin32RenderWindowInteractor
is inplace and should work, although I don't have a Win32 build to test it.  MakePackages.tcl is
simply a convience to help build the packages.  You may have missed the actual packages if you didn't
do a cvs update -d, because the code is in new subdirectories of VTK/Wrapping/Tcl

vtktcl, but this is of course a good idea. On the other hand 
> there is more 
> to thing to do to make it work on all platform, without too 
> much hassle to 
> maintain, etc.

  I'm assuming that you took care of makeing vtktcl cross-platform, and since I only re-packaged
it(pun intended), it should all work.

> Basically, what do you exactly wanted to know by voting ? The 
> fact that VTK 
> can be loaded component by component ? That's OK by me, no pb.

  As you mentioned, I simply took what you had already done and re-factored it.  The only real change
has to to with when packages are loaded, and modeling the dependancies of the kits in the package
mechanism.  I also changed the name, primarily because whe can't have name conflicts, and since this
is only applicable from Tcl, I dropped the "tcl" part of "vtktcl".

Sincerely,
-dan