An assessment of Tkinter and IDLE

[eb303]

On Aug 27, 11:22 pm, r <rt8... at gmail.com> wrote:
> ---------------------------------------------
> Python offical docs and Tkinter
> ---------------------------------------------
> *The Python docs barely cover anything related to actual Tkinter
> coding. At the minimum the Tkinter doc page should have a subpage for
> all the widgets available --which is very small(approx 15) and each
> subpage should list the available methods on that wiget.

I think the general idea behind the 'lack' of documentation is that it
would only double tcl/tk's own documentation. I've always used Tkinter
using the tcl/tk docs here:
http://www.tcl.tk/man/tcl8.5/TkCmd/contents.htm
and once you get used to how you transform tcl syntax to Python
syntax, it works pretty well. Maintaining a documentation for Tkinter
in the official Python docs would force people to run after tcl. I
understand why they don't want to do that, even if I'd love to see a
better Tkinter documentation too.

> ---------------------------------------------
> from Tkinter import *
> ---------------------------------------------
> *Too many noobs start out with the "from Tkinter import *" idiom,
> unknowing that they are horribly polluting their namespace. I feel
> that all (tkinter) code should follow the "import Tkinter as tk"
> policy and never use "from Tkinter import *". To push this agenda i
> propose all docs be modified so that no one should see such global
> import blasphemy again. We should at least keep all example code in
> the latter non-polluting form and frown heavily upon global imports in
> Tkinter code or any code for that matter.

Well, I just don't agree with you on this one. AFAIK, Tkinter has been
made to make the 'from Tkinter import *' idiom work without too much
namespace pollution. I've always used it, still use it today, and
never seen any problem with it.

I do agree that this might lead newbies to think it's ok for all
modules, and end up doing 'from os import *' and wonder why opening a
file with 'open' no more works. But this is the only problem I can
see.

> ---------------------------------------------
> Tkinter Constants
> ---------------------------------------------
> *The Tkconstants module needs to be removed *yesterday* because i
> think it reinforces sloppy coding styles. The main problem is with
> subtle bugs that are created when someone rebinds one or more of the
> constants, for example "W=20". At first i thought the constants were
> great but I quickly found out the shortfalls of such a Utopian
> approach . Since Tkinter allows strings to be passed-into widget
> constructors, we should remove the TkConstants immediately and force
> everyone to use strings instead...
>
>  #-- instead of this --#
>   w.pack(side=LEFT,fill=BOTH,anchor=W)
>
>  #-- do this --#
>   w.pack(side='left',fill='both',anchor='w')
>
> The few extra keystrokes are well worth the effort!

Well, again, I don't agree. I prefer having well defined constants
than having to type strings. If the values for the fill option could
be anything, well, OK. But they can't: they have to be either 'x' or
'y' or 'both'. So I prefer to have them defined in constants.

[snip comments on IDLE, which I don't use]

> ---------------------------------------------
> Tkinter Canvas
> ---------------------------------------------
> *The Tkinter Canvas widget should return (X,Y) pairs when calling
> canvas.coords(obj). The current implementation returns a flat array
> that is pretty much useless outside of canvas calls. Of course one
> could zip the coords into pairs, but it seems clumsy to call zip() on
> 2 LC's when Tkinter could, and should, do it for you.

We agree on this one, but it's a minor flaw.

> *Canvas needs a canvas.rotate() method for polygons, lines -- (easy).

All Canvas methods are actually forwarded to the underlying tcl
interpreter. So you might want to suggest that to the tcl guys.

> ---------------------------------------------
> Tkinter ComboBox -- where's Waldo?
> ---------------------------------------------
> *As much as i hate to support anything related to M$, Tkinter needs an
> M$ stlye combobox. Yes, I know Tix has combobox (*puke*), however
> using it is like pulling teeth. I have coded up an far more elegant/
> simple solution -- and yes, i know about the OptionMenu widget which
> serves a useful purpose but is NOT a good replacement for a REAL M$
> style combobox ;).

You don't seem to be aware of the new widgets in tk, which do include
a combo-box (and a lot of others BTW). See the ttk:: commands in the
tcl/tk documentation (link above). These widgets already have a Python
wrapper (see http://pypi.python.org/pypi/pyttk/0.3).

> *For instance, ComboBoxes need values that the user can select from,
> this is as universal as humans and oxygen. But sometimes you want to
> give the user a detailed set of values in the dropdown listbox and
> then insert an abbrieation of the value once selected, such as the
> case with state names...
>
>  New Mexico -> MN
>   California -> CA
>     Florida -> FL
>
> ...instead of the laborious and wasteful convention of overriding a
> method to insert this value from a mapping each time why not just pass
> a pointer to the mapping into the constructor and create a combobox
> that actually knows how to walk and chew gum!

Again, you might want to forward that to the tcl guys. And I do agree
it would be nice.

[snip code]

[snip Tix comments...]

Tix is more or less dead, since nearly all the widgets it provided
have now way better alternatives which have been included in the tcl/
tk core in the ttk package, including comboboxes and notebooks. You
might want to have a look at these.