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.

 

[Chris Angelico]

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

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

Does MouseClick mean Mouse Button Down, or does it mean Mouse Button
Pressed Then Released Within A Short Time Without The Mouse Moving In
Between? Both events are needed. Since you have MouseRelease, I am
guessing that it's MouseButtonDown (or MousePress, to parallel your
KeyPress/KeyRelease).

If you only have MouseDown and MouseUp events (or MousePress and
MouseRelease, whatever you wish to call them), then users have a lot
of trouble implementing CUA-compliant mouse-click handlers.

In the spirit of Ook and its predecessor, I propose one single event:
InputEvent. It will have a parameter that specifies the key ID or
mouse button that triggered the event; 0 means no key/button, and
indicates a mouse movement event. It will contain the location of the
mouse, and it's up to the program to keep track of the last known
mouse location, to detect movement. The beauty of this system is that
programmers can build interfaces that involve pointing at an object,
holding the four keys D-R-A-G, and moving the mouse to another
location and releasing those keys. This is far more intuitive than the
classic mouse-button way of dragging objects around, and avoids the
age-old debate of whether to drag with the left or right mouse button.
Tkinter should provide this facility so that all new programs will be
written with this in mind.

Chris Angelico

 

[rantingrick]

Does MouseClick mean Mouse Button Down, or does it mean Mouse Button
Pressed Then Released Within A Short Time Without The Mouse Moving In
Between? Both events are needed.

NO these six sequences are ALL you need!

I suppose you are "suggesting" that you will be unable to detect when
the mouse is "repeat-firing" or when you want to detect groups of
"rapid-succession" clicks (double, triple, etc)? This info is
contained in the 'event' object passed to the handler by Tkinter.

if event.time >[<] lasttime:
blah
if event.repeat:
blah

By removing all the unnessary sequence combinations you create
readable code and ease the leaning curve.

Since you have MouseRelease, I am
guessing that it's MouseButtonDown (or MousePress, to parallel your
KeyPress/KeyRelease).

Ok Mr. Pedantic. I suppose for unity sake we should use the sequence
name "<MousePress>" instead of <MouseClick>. I'll give you that one.

 

[Chris Angelico]

Ok Mr. Pedantic. I suppose for unity sake we should use the sequence
name "<MousePress>" instead of <MouseClick>. I'll give you that one.

It is very significant; if you call it Click, people will assume it
means Press, Release within a certain maximum time and without more
than a maximum amount of movement (in some cases 0 movement, others
permit a mickey or two).

Yes, that's all that's actually needed. But if you force programmers
to process the low-level events, you put load on them that they don't
need. It's possible to define every program in terms of a handful of
operations - do you want to ditch all of Python's rich syntax and
library in favour of that?

ChrisA