Re: Tcl::Tk Updates Ready for Release

On Tue, Oct 6, 2009 at 1:01 AM, Konovalov, Vadim (Vadim)** CTR ** <
[email protected]> 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