An assessment of Tkinter and IDLE
 

---------------------------------------------
Tkinter and IDLE Shortfalls
---------------------------------------------
*The following is an assessment of Tkinter as i have experienced it.
Even with all the problems i list below i strongly believe Tkinter is
a great starter GUI toolkit and we (the Python Community), must keep
and maintain this module for the foreseeable future.

*However, as my assessment will reveal, much needs to be done to
"freshen" up Tkinter and IDLE, and I am not just asking for someone to
fix these problems. I have already coded solutions for most of them
however, some of course still need work, and i would like to hear from
others on this subject too. So buckle your seat belts folks, cause
here we go...

---------------------------------------------
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. Here are two
great resources that really like from Fredrik Lundh and John
Shipman...

http://www.pythonware.com/library/tk...tion/index.htm
http://infohost.nmt.edu/tcc/help/pubs/tkinter/

....I must say that I prefer the latter written by John Shipman because
of the way he lists each widgets options in a nice table structure,
and then lists the methods below. And intersestingly enough, his
manual only weighs in at about 800kb completely uncommpressed and
unedited. I'll bet you a wooden nickel i can reduce it to around 500kb
for the official Python docs *wink*

*Sadly however neither of these great works is mentioned or linked in
the official docs Why?.

*I think a short-and-to-the-point reference, like the afore mentioned
along with a few links to full featured tuts would be a great addition
to the Tkinter section of the official docs and i would be happy to
help make this happen.

---------------------------------------------
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.

---------------------------------------------
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!

---------------------------------------------
IDLE Shell
---------------------------------------------
*IDLE and Pyshell are great but have major flaws in design. One of my
biggest complaints is the shell's eight space indention which
completely bloats your screen! Another annoying fact is that the prompt
(>>>) is actually inside the text widget. This design is all wrong!
The prompt should be in another widget to the left of the text so it
never gets copied or pasted. Or at-least have the copy/paste action
remove the initial four spaces and the prompt, but i think a full
separation of "prompt" and "text" are the best solution. The following
ASCII art won't win me any awards, but it may covey my idea. "W1"
holds the prompt and "W2" is the actual text editor.

<W1> <-------- W2 ----------->
>>> | for x in range(10): |
... | print x |
... | for y in range(x): |
... | print y |
|1
|2

And don't tell me about Geany or Pythonwin or emacs or vim or whatever
editor happens to float your boat. I know there are tons of great
editors out there but IDLE is most likely the first one a Pynoob will
use so it must be usable! IDLE and Tkinter are what make Python a
stater language -- after the beautiful syntax of course :)

---------------------------------------------
IDLE Editor
---------------------------------------------
*On M$ windows pressing the MMB without a motion causes the selected
text to be pasted at the insertion cursor, and holding it repeats the
action very quickly! Since IDLE has no horizontal scroll bar you must
use MMB to scroll left-right. I am quite happy that there is no
horizontal scrollbar since using MMB is much quicker, but the text
pasting action always ruins my day :(. This pasting action is a real
PITA and a waste of good processor time. I know how to override it
with a hack in IDLE, but many newcomers won't and will probably get
frustrated by it so this must be either fixed by hard coding IDLE or
allowing a user to turn is off in the config options dialog.

*Something that always gets a Python IDLE noob is "open-bracket-syntax-
errors" in IDLE. When Python throws this type of error normally the
only clue you will get from IDLE is to see the last line highlighted.
However, the missing or misplaced bracket is usually no where near the
end of the script. IDLE can be easily fixed to show a much closer or
even exact location of the last open bracket.

*The Find dialog forgets the regexp string after finding a match, this
can be a real time waster especially if you typed in a long expression
and need to tweak it just a bit for a second search! if the "regexp"
check box is selected the dialog should not replace the contents of
the Dialog.entry with the texts' selection. (easy fix)

*The replace dialog seems buggy when doing a "replace+find". Sometimes
it will highlight the next match but sometimes the highlight will
immediately disappear so you can't be for sure what you may be
replacing with the next push of the button? (could be a conflict with
the colorizer) Real aggravating! This seems to always happen when a
string is selected.

*One of my all time pet peeves with all text editors. Everybody repeat
after me...

"""NO TEXT EDITOR SHOULD EVER COPY AN EMPTY STRING TO THE
CLIPBOARD!!"""

....I can't tell you how many times I've had to re-copy some text
because i accidentally pressed <Control-C> instead of <Control-V>,
arggh! This bug needs to be fixed yesterday! Pressing <Control-C> with
no active selection should sound the error bell, not copy "".

*Using the goto-line command should highlight the requested line.
Currently all that IDLE does is place the insertion cursor at the
start of the requested line which is completely useless. One more line
of code in the goto method would make this action more useful

---------------------------------------------
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.

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

---------------------------------------------
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 ;).

*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!

[Warning: puesdo code ahead!]

class ComboBox(master, values, etc..)
def __init__(blahblahblah)
self.values = values
if type(values) == dict:
self.values = values.keys())
listbox.load(self.values)

def onUserPick(self, arg):
if type(self.values) == dict:
self.entry.set(self.values[arg])
return
self.entry.set(arg)

---------------------------------------------
Tix In General
---------------------------------------------
*I am not a big fan of the Tix Module. The idea behind the widgets is
great, but using most of them is a nightmare on elm street with Jason
Voorhees in hot pursuit. I have hacked my own far more elegant
versions of the more useful Tix Widgets and i feel mine are less buggy
and more user friendly. So i say lose Tix and go with my fix, or get
stuck with the Tix!

*Python is missing good docs for Tix. The only thing i can find is the
Tcl docs which are riddled with horribly cryptic tcl code.

---------------------------------------------
Tix NoteBook
---------------------------------------------
*The Tix.NoteBook widget has a bug. If you subclass Frame for your
toplevel window you can't create a notebook widget as a descendant of
the frame because it just blows chunks. The only way i have
successfully used the widget is by the noobish style...

>>> import Tix
>>> root = Tix.Tk()
>>> notebook = Tix.NoteBook...blah
>>> root.mainloop()

*Overall however i feel the IDLE "TabbedWidget" out-performs the
Tix.NoteBook by miles and is easier to use, although it does have a
few design problems that i have fixed. One of the most predominate
being the inability to see the tabs clearly. The selected tab should
"stand-out" from the others so a user can spot it quickly. Also there
is no reason to export TabSet class and this can clean up the code a
bit.

---------------------------------------------
Tix ComboBox
---------------------------------------------
*What is with that big ugly arrow? This widget is an exercise in
cruelty to humans, and thats all i will say about it!


---------------------------------------------
Final Thoughts
---------------------------------------------
Well, that is all i can remember for now. If you've made it this far
without losing your temper or your lunch well i am very surprised ;).
Anyway, give me some feedback on these ideas so maybe i can get
motivated to submit some patches/enhancements.

psst... help is welcome too ya'know :)

Re: An assessment of Tkinter and IDLE
 

On Aug 27, 11:22 pm, r <rt8...@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.

Re: An assessment of Tkinter and IDLE
 

Thanks eb303 for the wonderful post

I have looked over the new ttk widgets and everything looks nice. I am
very glad to see the death of Tix as i never much liked it anyhow and
always believed these widgets should have been in the main Tkinter
module to start with. The tree widget has been needed for some time.

However, i am not sure about the new "style" separation. Previously a
simple command like root.option_add('*Label.Font'...) accomplished the
same thing with less typing, but there may be a future method to this
current madness that i am unaware of...???

Re: An assessment of Tkinter and IDLE
 

With regard to Tkinter documentation, and in particular the newer, more
modern aspects thereof (e.g. ttk, styles, etc.) please have a look at
the tutorial at http://www.tkdocs.com

Would it be useful to link to this from the main Python Tkinter
documentation?

Mark

Re: An assessment of Tkinter and IDLE
 

On Aug 28, 11:12*am, Mark Roseman <m...@markroseman.com> wrote:
> Would it be useful to link to this from the main Python Tkinter
> documentation?
>
> Mark

Thanks Mark, but i would hate to see more links to TCL code in the
python docs. Whats the use of Tkinter if the docs are in TCL. Just
learn TCL and skip the Python middleman. But i don;t want to code in
TCL (*puke*) i much prefer Python even if i am calling wrapped TCL.
Not to mention this link is not a complete coverage of all the widgets
anyway.

We desperately need a complete reference for tkinter written with only
Python code that covers all widgets, all widget options, and all
widget methods. And this would be a minimal effort if someone would
just do it. Most of the information is already out there in various
locations around the net. We just need to compile, compress, and edit
it into one short and to the point reference material.

I will happily volunteer to create on my own or contribute to the docs
if i can get a guarantee from the tkinter maintainer that my work
would not be in vain.

Re: An assessment of Tkinter and IDLE
 

r wrote:
> On Aug 28, 11:12 am, Mark Roseman <m...@markroseman.com> wrote:
>> Would it be useful to link to this from the main Python Tkinter
>> documentation?
>>
>> Mark
>
> Thanks Mark, but i would hate to see more links to TCL code in the
> python docs. Whats the use of Tkinter if the docs are in TCL. Just
> learn TCL and skip the Python middleman. But i don;t want to code in
> TCL (*puke*) i much prefer Python even if i am calling wrapped TCL.
> Not to mention this link is not a complete coverage of all the widgets
> anyway.
>
> We desperately need a complete reference for tkinter written with only
> Python code that covers all widgets, all widget options, and all
> widget methods. And this would be a minimal effort if someone would
> just do it. Most of the information is already out there in various
> locations around the net. We just need to compile, compress, and edit
> it into one short and to the point reference material.
>
> I will happily volunteer to create on my own or contribute to the docs
> if i can get a guarantee from the tkinter maintainer that my work
> would not be in vain.
Please go ahead and try it. Having read the "Summary of Python tracker
Issues" on the python-dev mailing list, and followed from there to the
bug tracker, it seems that all input is greatly appreciated. For the
small issues the reply is often "Thanks, done". Some things get
rejected, and usually rightly so from what I can see. Others the issue
is closed with the half way house committed/rejected. Work that out for
yourself if you can.:)

--
Kindest regards.

Mark Lawrence.

Re: An assessment of Tkinter and IDLE
 

r wrote:

> Whats the use of Tkinter if the docs are in TCL. Just
> learn TCL and skip the Python middleman.

But Mark's tutorial at http://www.tkdocs.com/tutorial/index.html allows
you to select 'Python' as one of the languages you want to see the
example code in.

Too bad that the 'ttk' widgets are not mainstream yet.

Greetings,

--
"The ability of the OSS process to collect and harness
the collective IQ of thousands of individuals across
the Internet is simply amazing." - Vinod Valloppillil
http://www.catb.org/~esr/halloween/halloween4.html

Re: An assessment of Tkinter and IDLE
 

r <rt8396@gmail.com> wrote:
> On Aug 28, 11:12*am, Mark Roseman <m...@markroseman.com> wrote:
> > Would it be useful to link to this from the main Python Tkinter
> > documentation?
>
> Thanks Mark, but i would hate to see more links to TCL code in the
> python docs. Whats the use of Tkinter if the docs are in TCL.

The www.tkdocs.com site is 'language neutral' - currently the tutorial
covers Tcl, Perl, Ruby and yes Python, and allows you to switch between
any of those languages (or show all of them).

Re: An assessment of Tkinter and IDLE
 

On Aug 28, 5:48*pm, Mark Roseman <m...@markroseman.com> wrote:
(snip)
> Thewww.tkdocs.comsite is 'language neutral' - currently the tutorial
> covers Tcl, Perl, Ruby and yes Python, and allows you to switch between
> any of those languages (or show all of them).

True, however the coverage is incomplete. I would back this site if we
can get a complete coverage of all widgets in the Python language.

+0.1

Re: An assessment of Tkinter and IDLE
 

On Aug 28, 4:41 pm, r <rt8...@gmail.com> wrote:
> Thanks eb303 for the wonderful post
>
> I have looked over the new ttk widgets and everything looks nice. I am
> very glad to see the death of Tix as i never much liked it anyhow and
> always believed these widgets should have been in the main Tkinter
> module to start with. The tree widget has been needed for some time.
>
> However, i am not sure about the new "style" separation. Previously a
> simple command like root.option_add('*Label.Font'...) accomplished the
> same thing with less typing, but there may be a future method to this
> current madness that i am unaware of...???

The new widgets have been made mainly to make tk look better by making
it possible to use native widgets. The drawback is that it limits a
lot the possibilities of configuration you can have: on many
platforms, the looks of the widgets are decided by the user via a
system preference, not by the application programmer. This is why ttk
widgets are not configurable directly, because 'native' styles usually
don't allow it at application level anyway.

Keep in mind that the new ttk widgets are not replacements for former
widgets, but an addition to them. 'Old' widgets are still here, and
there is no plan I know of to remove them. If you want to do an
application with a very specific look, you can still use these.