Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

[Vadim K. <va...@ar...>]

> > In case we'll move out perlTk compatibility to separate
> > module, what will stay in Tcl::Tk? Only few very old
> > subroutines like "label", "toplevel" and so on?
>
> There are multiple levels of compatability.  The basic coding
> style, as noted above, it worth keeping.  However, there are
> a lot of Perl/Tk-isms that needn't be repeated in a "clean"
> Tcl::Tk, like modifications to core commands that do not
> reflect the usual behavior of Tk.  There is also a ton of
> extra widgets that could be moved over.

agreed.
And subroutine "Darken", for example, that was inserted unmodified from
perlTk, is a very first candidate to move out.


>
> I would also like to add a "DeclareWidget" sub in Tcl::Tk
> that allows the use (or some submodule) to declare that it is
> making a widget available (freeing up the need to hack the
> ptk2tcltk hash).  Something like:
>
> Tcl::Tk::Declare('BWTree',    # name in Perl
>      'tree',      # name in Tcl
>      'BWidget',   # required Tcl package
>      'Tree::use', # extra code (if necessary)
>     )

It seems to me that Tcl::Tk::Declare is similar in spirit to
create_ptk_widget_sub.
It could be renamed, its interface could be improved and so on... but
create_ptk_widget_sub actually creates widget's subroutine and used from
AUTOLOAD.

Or may be yours Tcl::Tk::Declare will be implemented using a call to
create_ptk_widget_sub?

existance of hash like %ptk2tcltk could be considered like not a hack, but
rather some kind of correct declaration of relationship (and its design
could still be improved to be, say, hash of hashes that declare properties
or something like that).

This hash allows us to create things only when needed.

Creating subroutines when required could be accomplished by standard perl's
Autoload.pm/Autosplit.pm, but I am not very like using it. It must be used
when module is large enough, and probably should be avoided otherwise (to
not complicate things)

> > May be instead of doing special compatiiblity layer for
> > perlTk, may be it could be reasonable to just use perlTk
> > syntax as main way of doing GUI in perl? Many people just
> > used to using that syntax from perl, and there are books about it.
>
> Right, as above, but with minor mods.  I've noticed that the
> Perl/Tk docs aren't accurate often enough that if we start
> to veer from them, it won't be a big deal.

Indeed.

> > BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} =
> > \&Tcl::Tk::Exists;" is commented out, it is possible to debug
> > Tcl::Tk code ising "ptkdb" debugger, which uses perlTk.
>
> Cool, but why is that one line needed?  Are you actually

I used it for trying some perlTk program, but this line really could be
deleted.

> loading Perl/Tk as well?  I intentionally turn on the
> tk_gestapo to avoid such interactions from occuring, as it
> may lead to undesired consequences.

it appears to be possible to do debugging even Tcl::Tk.pm with ptkdb, which
uses perlTk. And I did it succesfully.
I use ptkdb for quite long, and moving to console-mode debugger is not
convenient for me.

Vadim.