Tkinter binding question

[rantingrickjohnson at gmail.com]

On Wednesday, June 20, 2012 12:07:04 PM UTC-5, Frederic Rentsch wrote:
> [...] 
> Googling I chanced on an excellent introduction "Thinking in
> Tkinter" [...] He sets out identifying a common problem with
> tutorials: The problem is that the authors of the books want to rush
> into telling me about all of the widgets in the Tkinter toolbox, but
> never really pause to explain basic concepts. They don't explain how
> to "think in Tkinter".

Well. I have not analyzed this tutorial myself but i can tell you one thing for sure; most of the confusion regarding Tkinter comes NOT from improperly written tutorials NO, it is a direct result of the poorly designed Tkinter API itself! 

=================================
Some of the main problems follow:
=================================

*## 1. Failure to constrain event sequences:*
Tkinter allows users to bind a virtual cornucopia of possible event sequences. Some say this is a good thing because it allows freedom, i say it is contributing to unreadable and unmaintainable code bases. There are literally thousands of possible combinations a user could bind. Sure, this "freedom" might make the user feel good, but i can guarantee his code will be a spaghetti mess!

It is my firm belief, that only two Key Events and four Mouse Events should be allowed binding. Then, the callback should handle the dirty details -- which could include delegating details to one or many lower worker functions. In the real world you only need six possible events to process user input:

 * KeyPress(keyName)
 * KeyRelease(keyName)
 * MousePress(x, y, bNum)
 * MouseRelease(x, y, bNum)
 * MouseMotion(x, y, bNum)
 * MouseWheel(direction)

Checking the state of modifiers like Control, Shift, or Alt should be handled via an event object. Actually, all events should be a subclass of an EventHandler object.

*## Explicit parent/child relationships needs to be mandatory:*
Tkinter allows users to be lazy and omit the parent of a widget to save a few keystrokes on tiny little throw away scripts. In the real world, and even in small GUI applications, you would never want to do such a thing. I believe this methodology does irreversible damage to a new users brain. He fails to see the app->subwin->widget hierarchy from day one.

*## 2. Inconsistencies when constructing widgets:*
Most widgets expect a "parent" argument as the first argument, but not the case for Dialogs and other classes which allow you to pass "parent=blah" as a kw option. Without a parent, a dialog can not set up a proper transient relationship OR position itself properly over the correct window. Allowing this slothful developer behavior contributes to many frustrating user experiences.

*## 3. Inconsistencies between configuring widgets and configuring windows:*
Windows don't have a config method for things like: "title", "size", "etc". Instead they have methods like win.title("Title") or win.geometry("wxh+x+y"); which again breaks the consistency that is so important in any API! Not to mention the unessesaryily cryptic nature of a few of these methods.

*## 4. Failure to remove old tutorials from the web that are still teaching people to code Tkinter GUI's like it's 1991:*
This is a sad result of a dead community. And the few people who are remaining have become so partisan that nothing can get accomplish except, well, nothing. 

Congratulations Guido, are you proud of what you have created? Or rather, or you proud of what this community had degenerated into? (BTW those are rhetorical questions.)

I am still hoping beyond hope that some new blood will enter this community soon and inject some hope for the future. Guido is an old man. He has no passion anymore. I long for some new blood with a passion for consistency. People with the intuition required to create intuitive APIs. But most of all. People who have a "can do" community spirit.

A boy can dream.