On Jun 10, 1:13 am, "Martin v. Loewis" <mar...@v.loewis.de> wrote: > > That said, PerlTk didn't use Tcl did it? > > If you are referring tohttp://search.cpan.org/~srezic/Tk-804.028/- > this also has a full Tcl interpreter, in pTk/mTk, and uses Tcl_Interp > and Tcl_Obj throughout. From the Perl/Tk FAQ (*): > > "However, from a Perl perspective, Perl/Tk does not require any > familiarity with Tcl, nor does its installation depend on any Tcl code > apart from that packaged within Perl/Tk." > > They also explain > > "The pTk code proper is an externally callable Tk toolkit (i.e. a > re-write of the Tk 8.0 code that allows easier external linking & > calling, especially by perl)." > > I couldn't quite understand what they mean by that: the sources for > tcl/generic (for example) look fairly unmodified.
Perl/Tk, as referenced above, does indeed replace the Tcl interpreter with a bolt-on replacement using Perl internals. While this was workable, it was brittle and harder to maintain. Tkx (http://search.cpan.org/dist/Tkx/), a replacement Tk binding for Perl, authored by myself (core Tcl member, with knowledge of Perl internals as well) and others at ActiveState, reintroduced the Tcl binding in a very flexible way. It's actually the Tcl module (http:// search.cpan.org/dist/Tcl/) that has all the magic. Tk is loaded dynamically from that - Perl has no direct linkage to it. Tkx proved to be faster, more flexible and more extensible than the original Perl/Tk. The interface also took advantage of Tcl's stubs mechanism to provide a level of binary version independence (Perl's Tcl module can load any Tcl 8.4, 8.5 or 8.6 patchlevel without recompilation, with 100% functionality). If you look to revamp things, don't go down the path of trying to remove Tcl to get to Tk. Instead reconsider the approach to Tcl. A little bending might prove a much better match in the long term. Jeff -- http://mail.python.org/mailman/listinfo/python-list
