> From: Jan Dubois [mailto:j...@activestate.com] > 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.
