Multiplicity and Asininity in Tkinter Event API

[rantingrick]

############################################################
# Multiplicity and Asininity in Tkinter Event API!         #
############################################################

The problems with Tkinter events are two fold:

------------------------------------------------------------
Problem 1: Number Of Sequences Is Obscene.
------------------------------------------------------------
The sheer number of exposed sequences and possible user combinations
of sequences is overkill. You should never put the design of an API in
the hands of users of said API. Designing rock solid API's is about
giving users as much power as possible WITHOUT giving them too many
choices. Unfortunately, not only did the authors of Tkinter give
people choices, they gave them the power to create NEW choices...
CRIKEY!

------------------------------------------------------------
Problem 2. No Uniform Naming Convention.
------------------------------------------------------------
The sequence names follow an intuitive naming convention. Not only
that, but alias's exists for some of the combinations. Here are some
examples...

 <Button-1>
  <1>
 <ButtonRelease-1>
 <B1-Motion>
 <KeyPress>
 <KeyRelease>
 <KeyPress-a> | <a>
 <Contol-KeyPress-a>
  callback event inspection

------------------------------------------------------------
 Examples Of "Possible" Sequence Combinations
------------------------------------------------------------

Bindings for a single letter:
 <KeyPress>
 <KeyPress-a>
  <a>
 <Control-KeyPress-a>
  <Control-a>
 <Control-Shift-KeyPress-a>
  <Control-Shift-a>
 <Alt-Shift-Control-KeyPress-a>
  <Alt-Shift-Control-a>
 etc...

Bindings for Mice:
 <Button>
 <Button-1>
  <1>
 <B1-Motion>
 <ButtonRelease-1>
 etc...

This is only for one keypres and one button down event and this does
not EVEN include combinations of mice and key. Completely ridiculous!

As you can see this is far too many sequences for even a guru to
remember; and why should he? Why should he clog up his code with
handler after handler when only a handful are needed?

------------------------------------------------------------
 SOLUTION:
------------------------------------------------------------
I can tell you first hand that out of all these thousands of sequences
we only need six to cover user inputs. YES, you heard me correctly.
SIX!

Here are the six i propose:

 <KeyPress>
 <KeyRelease>
 <MouseClick>
 <MouseMotion>
 <MouseRelease>
 <MouseWheel>

That's it. Go ahead, try to prove me wrong!

------------------------------------------------------------
 Potential Naysayer's Arguments:
------------------------------------------------------------

Argument_1:
    Wah! But i don't like to have to process possible all
    three (or more) mouse buttons in the same event
    handler.. Wah, Wah!

Rebuttual_1:
    No problemo amigo, just dispatch those specific button
    events to specific handlers. Here kiddo, watch this...

    def onMouseClick(num, pos, rootpos):
        if num == 1:
            self.onButtonOneClick(num, pos, rootpos)
        if num == 2:
            self.onButtonOneClick(num, pos, rootpos)
        etc...
        etc...

------------------------------------------------------------
 Conclusion:
------------------------------------------------------------
It's time to start cleaning up this library. All you @-holes fought me
long ago about how GREAT Tkinter is. I don't think Tkinter is great
however i do believe it has great potential.

Now it the time to put up or shut up. I AM willing to put forth the
effort. I have documented the deficiencies, and i have cleaned up
code. I have offered up more intuitive API interfaces. NOW it's high
time for the dev's to come forward.

  http://www.youtube.com/watch?v=XzcWwmwChVE