Ricardo Medina had a good suggestion today. He said that since we have a get_gui_value method, why not a set_gui_value to go with it? (Currently, we use an update method to change GUI properties.) I thought that was a good idea, so I started to implement it.

Inevitably, what seemed like a relatively simple change became a bit more complex. For one thing, get_gui_value does, in fact, retrieve the value from, a GUI element. But one can update properties of GUI elements, such a color, size, etc., other than its value. So, set_gui_value seemed like the wrong name. I finally arrived at the pair of names: gui_get and gui_set. The actual code (in SimEngine) looks like this.

@staticmethod 
def gui_get(key):
    value = SimEngine.values.get(key, None)
    return int(value) if isinstance(value, float) and value == int(value) else value

@staticmethod
def gui_set(key, **kwargs):
    widget = gui.WINDOW[key]
    widget.update(**kwargs)

The method gui_get does exactly what get_gui_value used to do. It's just a name change.

The method gui_set is a bit more complex. It is used instead of update. For example, instead of

gui.WINDOW['rows'].update(value=len(self.ca_lines))

on the last line of __init__ in ca_outline, one now writes,

SimEngine.gui_set('rows', value=len(self.ca_lines))

'rows' is the key for the widget to be updated. The update is to set value to be len(self.ca_lines).

So, in practice, there is little difference between using update and using gui_set.

If you look at the implementation of gui_set, you'll see that it's a bit tricky. (I had to ask on StackOverflow) to find out how to do it.

I believe I've updated all the code on GitHub to reflect this change. (In making the changes I commented out the lines that use update and put the replacement line using gui_set directly below it. That should make it easier to see the change.) Let me know if you find changes I missed.

There is a second relatively minor change. Instead of  handle_event_and_values, the method is now simply handle_event. However, handle_event has an event parameter whereas handle_event_and_values had no parameters (except self). In other words, handle_event is now passed the event that triggered it. Before you had to get the event yourself. This makes sense since it is an event that SimEngine doesn't recognize that leads it to call handle_event. So it makes sense to pass that event to the method that will handle it.

So instead of

def handle_event_and_values(self):
    """
    This is called when a GUI widget is changed and isn't handled by the system.
    The key of the widget that changed is the event.
    If the changed widget has to do with the rule number or switches, make them all consistent.

    This is the function that will trigger all the code you write this week
    """
    # Handle color change requests.
    super().handle_event_and_values()

    event = SimEngine.get_gui_event()
    if event in ['Rule_nbr'] + CA_World.bin_0_to_7:
        self.make_switches_and_rule_nbr_consistent()

handle_event is now defined as follows.

def handle_event(self, event):
    """
    This is called when a GUI widget is changed and isn't handled by the system.
    The key of the widget that changed is the event.
    If the changed widget has to do with the rule number or switches, make them all consistent.

    This is the function that will trigger all the code you write this week
    """
    # Handle color change requests.
    super().handle_event(event)

    if event in ['Rule_nbr'] + CA_World.bin_0_to_7:
        self.make_switches_and_rule_nbr_consistent()

The preceding discussion is probably longer than most of you care about. (In practice, the actual changes are relatively minor.) But I wanted to show you the kind of thought one should put into one's code--whether or not you agree with the actual decisions I made about these specific issues. (If you disagree, what alternative would you suggest? After all, this started with a suggestion by Ricardo Medina.)