> As you found, the versions of all the .pm files should be > cleaned up. This was something I had overlooked. Some of > these versions are left over from the perl/tk version. > Probably should make all of them match the main version of > the Tcl::Tk package.
okay, we'll decide that later, after more cleanups. > > 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. > > I not sure if the perl/tk files can be separated out from the > Tcl::Tk files. Most aren't direct copies of the perl/tk > files. The perl/tk files were used as a starting point, and > then hand-edited to get to work with Tcl::Tk. yes, I understand that, but something should be done, because the problem is not non-existent. > > 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 wonder, is it at all possible? Surely, there are yet other alternatives. > > Maybe a better way of identifying the perl/tk files would be > to put a special text header in them (e.g. "#### Imported > from perl/tk ###'), that way you could grep for some special > text, and get a list of perl/tk-derived files. well, IMO, if all else fails, this would be better than nothing. Other alternative to call such derived files somehow recognizable. But leaving all in one large heap is not the way to go. > Also, what the "mktransgif.tcl" file for? Its not even > in the Manifest. > > It doesn't do anything. Some overactive copy/paste on my part > :) . I just removed it from svn. thanks. keep moving forward in this direction :) :) Actually Tcl::Tk was just one single file, plus some 2 .pm files which could be avoid. Honestly, I want to avoid such a mess that currently is in perl/Tk. > > > > And, IMO, all versions of all files should be better > thought. I see that Tcl::Tk version didn't change, and > Tcl::Tk::Widget does not have version at all. > > > > Agreed. All .pm files need a version. Same as the version of > the overall Tcl::Tk package IMO. Alternatively, a version > number derived from svn. I guess you're right. May be there should be something like $Tcl::Tk::Widget::VERSION = $Tcl::Tk::VERSION; ? just a thought. But still, why you really put that module into separate file? It is surely must be loaded in 100% cases. May be it should be returned back? just another thought, maybe you're right moving it outside. Need to decide. Regards, Vadim.
