GUIs - A Modest Proposal
Mark Roseman
mark at markroseman.com
Wed Jun 9 11:58:13 EDT 2010
"bart.c" <bartc at freeuk.com> wrote:
> "Grant Edwards" <invalid at invalid.invalid> wrote in message
> >> Since Tk already provides a basic GUI toolset, and Python can interface
> >> with it more directly than it can with other toolkits
> >>(PyGui -> PyGtk -> Gtk -> Xlib),
> >
> > Compare that to this:
> > TkInter -> Tcl -> Tk -> Xlib
> Is the Tcl intepreter really need to use this GUI? Why not:
> (Pyton ->) Tkinter-API -> Xlib ?
The Tk library was not built as a straight C/C++ library that interfaces
to Xlib (or the Windows or Mac libraries), with a Tcl binding on top of
that.
Tk was built expressly as a GUI toolkit for Tcl, and it uses Tcl very
extensively throughout its implementation. While there is a C API, it
does not expose anywhere close to everything you'd need without making
calls to the Tcl interpreter. Whether you consider this a good or bad
thing, that's the way it is.
So removing Tcl from the Tk library is not by any means practical. Of
the dozens of dynamic languages with Tk bindings, almost all interface
to Tk through the Tcl interface.
The one notable exception is PerlTk, which went out of its way to
extract Tcl from Tk, a herculean effort. Though they managed,
maintaining it was virtually impossible, so they are stuck with a 15+
year old version of Tk, taking into account none of the improvements
made during that time. The preferred Perl interface to Tk is a newer
one called pTk, which wraps Tk's Tcl API, meaning it can easily keep up
to date with improvements in Tk. And the wrapper code itself is
frighteningly small, what amounts to an exceedingly clever but minor
engineering effort.
I hope this explains why trying to have Tkinter work without Tcl would
be a non-starter.
Mark
More information about the Python-list
mailing list