RE: Tcl::Tk Updates Ready for Release

> From: Jan Dubois [mailto:[email protected]] 
> On Mon, 05 Oct 2009, Konovalov, Vadim (Vadim)** CTR ** wrote:
>  
> > >
> > > I put the bitmap files (i.e. the xbm, xpm, etc files) in the
> > > Tcl/Tk directory, because perl/tk puts them in a similar
> > > place. Bitmap files for perl/tk end up in the Tk directory
> > > after installation. They could possibly be moved to a bitmaps
> > > directory under the Tcl/Tk directory, as long a
> > > Tcl::Tk->findINC can still find them.
> > 
> > we are not obliged to follow bad designs. findINC is bogus and it
> > should not be a reason for anything otherwise inconvenient.
> 
> You may want to take a look at File::ShareDir (and 
> File::ShareDir::Install
> for MakeMaker installation support).

So MakeMaker will find it even in subdirectory, but still will install to ./site/lib/Tcl/Tk/ directory?

> 
> > >
> > > If we separated out the perl/tk files, it could cause some
> > > confusion in converting from perl/tk code to Tcl::Tk. For
> > > example, the Font.pm package is currently in the Tcl/Tk
> > > directory, so it gets used with a "use Tcl::Tk::Font", which
> > > is very similar to the perl/tk sytax of "use Tk::Font". If
> > > the Font.pm package was moved to another directory (like
> > > "Tcl/Tk/perltk"), then you would have to use "use
> > > Tcl::Tk::perltk::Font".
> > 
> > Would the "Tcl::pTk::Font" be reasonalble alternative?
> > 
> > This may be problematic with CPAN indexing, I wonder, are there any
> > modules that do something like this? On the one side, the "Tcl" name
> > space is likely to be free for our usage, but on the other 
> hand such a
> > pollution to another namespace could be prohibited.
> 
> I don't think using different namespaces based on the codes heritage
> is a good idea. 

yes, I easily believe this is so.

> Namespaces should be chosen that make the most
> sense from the *users* perspective.  Why would the user care that
> the Font class *implementation* was somehow inherited from the old
> PerlTk package and not written from scratch for Tcl::Tk?

AFAIR there is some CPAN module that creates something like "symbolic references" to perl packages/namespaces.

I.e. you create Tcl::Tk::perlTk::Font and then do a symbolic link to somewhere shorter link. May be this is the way to go?

OTOH we do not need short path to "Tk::Font" - user should not be aware of it at all, all should be behind the scenes.

> 
> You can organize your source code in the  distribution into
> multiple directories (and uses multiple Makefile.PLs to build
> them and install them into the correct location), but that is
> still nothing that the end user should need to worry about.

I want for the files borrowed or cloned from perl/Tk to be placed and to be installed into separate directory.

Also, I really really want to keep Tcl::Tk small and simple.

Perl/Tk is slow as a dog, I do not want this feature to be borrowed from perl/Tk also.
Yet, I'll adopt Tcl::Tk to perl6 (for real, this time :) ) and I want it be back one single file.

So I think we should consider undo-ing splitting old Tcl::Tk module into small pieces.

Regards,
Vadim.