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.
--
http://mail.python.org/mailman/listinfo/python-list
