1.1 Smart-UI

We start this exploration toward MVC with the most trivial and simplistic design: Smart UI, also known as Autonomous View.

Note

A confusing characteristic of MVC literature is that different names are used to express the same concepts. Vice-versa, it is also common that the same name is used to express totally different concepts. We accept this by proposing the most common names, reporting “also known as” names, and stressing differences when appropriate.

The Smart UI approach uses a single class to handle all responsibilities we expect from a GUI program:

• Receives user driven events, such as mouse clicks and keyboard input
• Holds application logic to convert user driven events into changes of application state
• Holds the relevant application state
• Performs visual rendering of its state

As an example implementation of a Smart UI, consider a click counter application, which shows a button with a number. The number is increased every time the button is clicked.

The code is as follows:

import sys
from PyQt4 import QtCore, QtGui

class Counter(QtGui.QPushButton):
    def __init__(self, *args, **kwargs):
        super(Counter, self).__init__(*args, **kwargs)
        self._value = 0
        self._update()

    def mouseReleaseEvent(self, event):
        super(Counter, self).mouseReleaseEvent(event)
        self._value += 1
        self._update()

    def _update(self):
        self.setText(unicode(self._value))

app = QtGui.QApplication(sys.argv)
counter = Counter()
counter.show()
app.exec_()

The application’s main and only visual component, Counter, is derived from a single GUI class, a Qt QPushButton. Observe in particular how Counter is

1. Storing the current click count value in the member variable self._value.
2. Handling the logic that modifies self._value. Every time the button is clicked, Qt invokes mouseReleaseEvent automatically. In this method the click counter is incremented.
3. Synchronizes the aspect of the button with the current self._value, by invoking setText.

This minimalist design seems appealing for its simplicity and compactness. It is a good starting point for trivial applications, and the one most likely to be implemented by novices in GUI programming, but it does not scale well for larger applications, where state, user events and graphic layout are more complex and intertwined and need to change often under development pressure. Specifically, observe the following issues:

• Access and modification of the current state from outside is cumbersome, being contained into the all-encompassing visual object: external objects that want to modify the current counter need to make sure that the represented value is synchronized, for example, forcing a call to _update(), or having the Counter object provide a setValue() method.

• It is difficult for other visual objects to report the same information, maybe with two different visual aspects (e.g. both as a counter and as a progress bar)

• The resulting class is difficult to test. The only way to stress it through its public interface and functionality is to actually probe it with GUI events, which is impractical for reasons we will examine later.

• The logic dealing with visual aspect (i.e. handling and layouting widgets, updating the label on the button), interaction aspect (handling the user initiated mouse click to perform the increment operation) and business aspect (incrementing the counter) are of different nature, and would be better kept separated. This would ease testability, simplify code understanding and interaction.