Keypress Input

Rick Johnson rantingrickjohnson at gmail.com
Wed Jul 15 21:03:23 EDT 2015


On Friday, June 19, 2015 at 12:20:14 AM UTC-5, Christian Gollwitzer wrote:

> The nonsense starts here:
> 
> [...snip code...]
> 
> it seems you don't understand event based programming.

Duh. No need to abuse the lad.

> It waits for the user input and does the dispatching, i.e.
> when a key is pressed, then according to your bindings,
> the functions red1, yellow1, blue1 are called, which set a
> variable but do not do nything else.
> 
> Now your job is to also do the functionality there, i.e.
> you have to reformulate your task (waiting for red, then
> blue...) as a state machine. Alternatively you can
> circumvent to redo the logic in a state machine by using a
> coroutine.

State machines? Co-routines? Dispatching? Bindings? Are you
purposefully attempting to scare the OP away from GUI
programming forever, or merely practicing for your next tenure
exam? Heck you're scaring me away and i have years of GUI
programming experience under my belt!

> You should read a text about GUI programming, or more
> specifically event based programming, to understand your
> mistake.

Christian, peppering a student with a barrage of technical
verbiage and then smacking them in the face with that tried
and true knee-jerk-reactionary condescension of RTFM, is
hardly the reaction that the OP deserves when he *DID*
attempt to formulate working code from the sample that Laura
provided. And even *IF* his attempt was an abysmal failure, we
should strive to provide more information than simply: "go
study the history of GUI design and get back to us in a year
or two". Of course, we don't want to write the code for him,
but his attempt does warrant a few extra clues.

============================================================
 @ John
============================================================

You may have solved your input capturing problem, and i
don't think a GUI is the preferred solution for a
graphically deficient device anyhow, but you may well need a
GUI in the future, and this would be a fine example from which
to learn.

So you want to know about Event Driven Programming do ya?
Well then, skip the boring lectures and the hours of eyeball
parsing techno-babble-prose and listen up!

You see, we, as humans, emulate a version of Event Driven
Programming (or EDP) in our everyday lives as something i
shall henceforth refer to as Event Driven Reactions (or
EDR). And these EDRs are codified as culturally acceptable
reactions to external stimuli during the course of
interpersonal relations. 

For instance: 

  If we meet someone for the first time and they extend
  their hand, then we should extend ours and engage in the
  "hand shake" or the "fist bump" (depending upon cultural
  norms). And if you're in one of those really freaky cultures
  you may have to kiss someone... YUCK!
    
  Or if someone insults us with a sexual advance, and we're
  of the female persuasion, and they're of the male
  persuasion: then we might react (as "Manolo" found out in 
  that famous scene from "Scarface") by slapping them *SMACK*
  
The point is: The action of us reacting to external stimuli
(based on predefined rules) is the exact nature of Event
Driven GUIs. When we write GUI code under this paradigm, we
need to follow a few design rules.
  
  (1) DEFINE/CREATE THE REQUIRED GUI COMPONENTS
  
  Here we define the window(s) and the required widgets that
  shall provide an interface between our users and our code.
  
  (2) DEFINE RULES FOR REACTIONS TO EXTERNAL STIMULI
  
  Here we bind events (keyboard, mouse, joystick, etc) to
  callbacks (aka: functions in Python) that our "master
  control program" (aka: Tkinter in this instance) will
  execute when the defined event is recieved.
  
Now you may be asking yourself: "But i did that already! Why
does my code fail to produce required results?"

Hmm, it seems (as Christian pointed out) you made the fatal
flaw of starting the event loop before your logic could
execute. However. Even if your logic was allowed to execute,
it would fail to produce the desired results. 

============================================================
 THE ROAD TO ENLIGHTENMENT:
============================================================

I have re-packaged Laura's basic example into a class format
that utilizes a paradigm known as Object Oriented
Programming (or OOP). Of course, you're not required to
write code utilizing this format, but i feel it may be
easier for a GUI novice to understand the entire structure
of this program when the relevant bits are in near proximity
to one another, rather than spread around a module like a
spilled carton of toothpicks on the floor -- because, not
all of us are blessed with the narrowly focused genius of
the "idiot savant"!

Now, conceptualize the entire class as representing the window
whilst it's "alive", and the methods defined in the class as
"personal reactions" to events that the window encounters
during it's lifetime. You should think of the window as a
unique object in two dimensional space, just as you and i
are unique objects in three dimensional space.

Furthermore, looking over the code you should recognize two 
distinct "syntactical groupings" 
  
  (1) The "App object"

  (2) The instantiation of the that App object 
      (psst: look below __name__ == '__main__')

The object and the instantation of the object are now
clearly defined by utilizing a "naturally linear" syntactical
progression.

Moreover, the functional behavior of the object is defined
from *INSIDE* the object and *NOT* in the next room or next
solar system. Most humans find this format to be a more
natural way of writing code as it mirrors the conceptual
observation of real life systems, objects, and the encapsulation
of their innate behaviors. Enjoy.

## BEGIN "AWESOME CODE" ##
import Tkinter as tk
from tkMessageBox import showinfo, showerror

MSG1 = """\
To begin retinal stimulation, press r or g or b on your keyboard
Hold key down for extended stimulation!
"""

class App(tk.Tk):
    def __init__(self):
        tk.Tk.__init__(self)
        self.bind("<KeyPress>", self.evtKeyDown)
        self.bind("<KeyRelease>", self.evtKeyUp)
        self.protocol("WM_DELETE_WINDOW", self.evtDeleteWindow)
        w = tk.Label(self, text=MSG1)
        w.pack()
        self.config(bg='white')
        self.geometry('500x500')
        self.focus_set()

    def evtDeleteWindow(self):
        showinfo("The window is Dying", "Goodbye cruel world!", parent=self)
        self.destroy()

    def evtKeyDown(self, event):
        key = event.keysym.lower()
        alert = False
        if key == 'r':            
            self.config(bg='red')
        elif key == 'g':
            self.config(bg='green')
        elif key == 'b':
            self.config(bg='blue')
        else:
            msg = 'I *TOLD* you to press r or g or b, not {0!r}!'.format(key)
            showerror('', msg, parent=self)

    def evtKeyUp(self, event):
        self.config(bg='white')

if __name__ == '__main__':
    app = App() 
    app.title('Retina Stimultor')
    app.mainloop()
    print "This code only executes *AFTER* the mainloop call returns!"
## END "AWESOME CODE" ##


PS: Don't be too upset at Christian. He's probably just
grumpy due to the excessive trolling and emotional warfare
that plagues this fine group. I'm sure he did not mean to
offend. Of course it could be that he's having withdraw
systems due to my extended absence. Who knows? Perhaps if i
found this group to more intellectually stimulating i might
be inclined to participate on a regular basis.



More information about the Python-list mailing list