On Tue, Oct 6, 2009 at 1:01 AM, Konovalov, Vadim (Vadim)** CTR ** < vkonova...@alcatel-lucent.com> wrote:
> > 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. > > Yeah, findINC is annoying, but it is used in a lot of perl/tk modules and demo code. I think it still has to be supported for perl/tk compatibility at some level. > > > > 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. > Other than the bitmap files (which I think can be put in a separate directory with no problems), I think any changes in the .pm file locations is going to cause confusion to the end-user, who probably doesn't care about the history of the files included (i.e. whether they were modified from perl/tk or coded from scratch). Is there any other issue with having the perl/tk derived files in the same directory as the Tcl::Tk original files? >From a software maintenance standpoint, I can see that you would want to know, so you could make any bug-fixes made to the perl/tk codebase also in the Tcl::Tk codebase. Other than that, is there some other reason why you want the files separated? > > > > > 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. > > Perl/Tk definitely has a mess of files. I think the biggest mess there is the duplication and modification of the Tcl/Tk C-code. Using your Tcl::Tk package, I think we can provide almost 100% compatibility with a lot of existing perl/tk code out there without having to include and compile modified Tcl/Tk c-code like perl/tk does. There has been a lot of .pm files added to achieve perl/tk compatibility (including pure perl megawidget support). Believe me, I didn't add anything extra that wasn't required for the task. > > > > > > > > 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. > > With the extra code added to the Tk.pm module, it was getting really big and hard to manage so I split-out the Widget package to a separate file. Also, most perl coding standards I have seen try to avoid putting more than one package into a single .pm file (usually one package = one file is preferred). Regards, -John