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

[Sebastien BARRE]

Hi Dan,

At 04/09/01 08:31, Blezek, Daniel J (CRD) wrote:

>   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.

Definitely. I do agree with you.

>   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.

OK. Actually packages do allow this sort of flexibility, but since it's not 
required at the moment, let's not worry about that.

>   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

Yes, it was my mistake here and a bad coincidence : I was moving from 
Win2000 to Win98, and at the time I updated my CVS, my $HOME env var was 
not set and WinCVS could not find my .cvsrc, which actually states that -d 
should be used with "cvs update". Jesus...
I will evaluate all that stuff again :)

>   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".

OK Dan.

At 04/09/01 08:35, Blezek, Daniel J (CRD) wrote:

> > >and dependant libs
> > >vtk - loads all the kits, and colors.tcl, etc...
> >
> > After some thinking I guess :
> >          vtk : should load libvtk*Tcl only. This looks more
> > logical, don't
> > you think so ?
>
>   Yes, but perhaps vtk isn't the place for that, I had intended the vtk 
> package to be the mother of
>all vtk packages, and the only thing you need to require to use everything 
>in vtk.  For beginners,
>it's much easier to use "package require vtk" than to have to know what's 
>in each of the packages.

Sure, but even if you are a beginner (and I'd even say "especially if you 
are a beginner"), you can be in trouble because the "package require vtk" 
will load a lot of stuff in the global space. That kind of thing is "easy" 
to check for an expert, but is tricky otherwise :) A compromise between the 
knowledge required to have a clean space and the amount of stuff that are 
loaded into the global env would be cool.

OK, I'm not sure I can work on that this week, so basically I'll be happy 
to discuss and improve this new approach once I'll be at Kitware. In the 
meantime, I don't think we should upgrade all scripts from "package require 
vtktcl" to "package require vtk" until it has been tested thouroughly on 
Win32, don't you think so ?

Sincerely
Seb