In our previous article, we developed a simple Python tkinter user interface for a rock[paper-scissors game. However, if you tried the code, you might stumble on one infelicitous problem:
The program comes up with no boxes checked, but if you click on the Play button, the program plays a game anyway, assuming that Scissors had been selected. Why does this happen?
When we set up the 3 radio buttons we set the IntVar to -1 so that none of the buttons would be selected.
ChoiceButton.gvar = IntVar()
ChoiceButton.gvar.set(-1) # none selected
ChoiceButton(lbf, "Paper", 0).grid(row=0, column=0, sticky=W)
ChoiceButton(lbf,"Rock", 1).grid(row=1, column=0,sticky=W)
ChoiceButton(lbf, "Scissors", 2).grid(row=2,column=0, sticky=W)
But let’s see what happens when our code checks the index to see which button is selected:
# play one game def playit(self): index = int(ChoiceButton.gvar.get()) self.play = Player.moves[index]
The index returned is -1 as expected. And the three moves are in a tuple:
moves=("P", "R", "S") #tuple of legal play characters
And what do we get when we ask for
Python is unusual among common computer languages in that indexes of less than zero in arrays (lists), strings and tuples mean start at the end and work backward. So the index of -1 gives us the character ‘S’ and -2 would get us ‘R’ and so forth. This also rotates around so that -4 would give us ‘S’ again. In other words, Python apparently takes the index modulo the length of the array so that negative indexing never gives us a out of bounds error. If we had set the gvar to 3 or more, no radio button would have been selected, and an error would occur.
So, how do we prevent this infelicitous behavior, where a player can click on the Play button when no radio button has been selected? It would be possible to trap this out-of-range indexes and prevent play from taking place, but since the program assumes that only legal plays can occur, this would take a good deal of careful checking.
Instead, we do what we should have done in the first place and disable the Play button until a radio button has been clicked.
But how do we turn the button back on? We recommend using a Mediator.
The Mediator Pattern
The Mediator Design Pattern is a really simple little software trick that keeps classes from having to know about the internal workings of other classes. And when you are dealing with GUI widgets, there might be a number of GUI classes that needn’t know about each other.
Instead, we create a Mediator class and tell it about the push button and the radio buttons, and let it do the work. The Mediator keeps a reference to the pushbutton and receives a call when a radio button is clicked. The whole thing is just a few lines of code:
class Mediator() : def __init__(self, button): self.button = button # save the button reference # called when a radiobutton is selected def choiceClick(self): self.button['state']=NORMAL # enable the button
So, how do we go about connecting up this Mediator? We create the button and then create the Mediator, passing it a reference to that button:
playButton = Button(root, text="Play", command=self.playgame) playButton.grid(row=3, column=0, pady=20) playButton['state'] = DISABLED med = Mediator(playButton) # create the Mediator
So, now the Mediator knows about the button. What about the radio buttons? You may recall that we have derived a ChoiceButton class so it can contain the gvar variable. All we need to do is pass the mediator reference to each button as we create it:
ChoiceButton(lbf, "Paper", 0, med).grid(row=0, column=0, sticky=W) ChoiceButton(lbf, "Rock", 1, med).grid(row=1, column=0, sticky=W) ChoiceButton(lbf, "Scissors", 2, med).grid(row=2, column=0, sticky=W)
And the ChoiceButtpm itself creates a command that calls choiceClick in the Mediator:
class ChoiceButton(Radiobutton): gvar = None def __init__(self, rt, label, index, med): super().__init__(rt, text=label, variable=ChoiceButton.gvar, command=self.comd, value=index) self.med = med # Save the Mediator reference def comd(self): self.med.choiceClick() #call the Mediator
So anytime a ChoiceButton is clicked, it calls choiceClick and that enables the Play button.
So, to summarize, we use the Mediator to take care of classes that need to send each other information. In this case, clicks on the radio buttons tell the Mediator to enable the Play button. Before that it is disabled. In general, the Mediator is an excellent solution when two or more classes need to tell each other about click events and the like and prevents you having to write GUI classes that know about other GUI classes, and thus getting entangled.
Code for this and the previous two articles can be found on GitHub at jameswcooper/articles