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