GUIs - A Modest Proposal

[Jeff Hobbs]

On Jun 10, 1:13 am, "Martin v. Loewis" <mar... at 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