- A Pop-Up Alert in 25 Lines
- An Expression Evaluator in 30 Lines
- A Currency Converter in 70 Lines
- Signals and Slots
- Summary
- Exercise
This chapter is from the book
This chapter is from the book
This chapter is from the book
An Expression Evaluator in 30 Lines
This application is a complete dialog-style application written in 30 lines of code (excluding blank and comment lines). "Dialog-style" means an application that has no menu bar, and usually no toolbar or status bar, most commonly with some buttons (as we will see in the next section), and with no central widget. In contrast, "main window-style" applications normally have a menu bar, toolbars, a status bar, and in some cases buttons too; and they have a central widget (which may contain other widgets, of course). We will look at main window-style applications in Chapter 6.
This application uses two widgets: A QTextBrowser which is a read-only multi-line text box that can display both plain text and HTML; and a QLineEdit, which is a single-line text box that displays plain text. All text in PyQt widgets is Uni-code, although it can be converted to other encodings when necessary.
The Calculate application (shown in Figure 4.3), can be invoked just like any normal GUI application by clicking (or double-clicking depending on platform and settings) its icon. (It can also be launched from a console, of course.) Once the application is running, the user can simply type mathematical expressions into the line edit and when they press Enter (or Return), the expression and its result are appended to the QTextBrowser. Any exceptions that are raised due to invalid expressions or invalid arithmetic (such as division by zero) are caught and turned into error messages that are simply appended to the QTextBrowser.
)
Figure 4.3 The Calculate application
As usual, we will look at the code in sections. This example follows the pattern that we will use for all future GUI applications: A form is represented by a class, behavior in response to user interaction is handled by methods, and the "main" part of the program is tiny.
from __future__ import division import sys from math import * from PyQt4.QtCore import * from PyQt4.QtGui import *
Since we are doing mathematics and don't want any surprises like truncating division, we make sure we get floating-point division. Normally we import non-PyQt modules using the import moduleName syntax; but since we want all of the math module's functions and constants available to our program's users, we simply import them all into the current namespace. As usual, we import sys to get the sys.argv list, and we import everything from both the QtCore and the QtGui modules.
class Form(QDialog):
def __init__(self, parent=None):
super(Form, self).__init__(parent)
self.browser = QTextBrowser()
self.lineedit = QLineEdit("Type an expression and press Enter")
self.lineedit.selectAll()
layout = QVBoxLayout()
layout.addWidget(self.browser)
layout.addWidget(self.lineedit)
self.setLayout(layout)
self.lineedit.setFocus()
self.connect(self.lineedit, SIGNAL("returnPressed()"),
self.updateUi)
self.setWindowTitle("Calculate")
As we have seen, any widget can be used as a top-level window. But in most cases when we create a top-level window we subclass QDialog, or QMainWindow, or occasionally, QWidget. Both QDialog and QMainWindow, and indeed all of PyQt's widgets, are derived from QWidget, and all are new-style classes. By inheriting QDialog we get a blank form, that is, a gray rectangle, and some convenient behaviors and methods. For example, if the user clicks the close X button, the dialog will close. By default, when a widget is closed it is merely hidden; we can, of course, change this behavior, as we will see in the next chapter.
We give our Form class's __init__() method a default parent of None, and use super() to initialize it. A widget that has no parent becomes a top-level window, which is what we want for our form. We then create the two widgets we need and keep references to them so that we can access them later, outside of __init__(). Since we did not give these widgets parents, it would seem that they will become top-level windows—which would not make sense. We will see shortly that they get parents later on in the initializer. We give the QLineEdit some initial text to show, and select it all. This will ensure that as soon as the user starts typing, the text we gave will be overwritten.
We want the widgets to appear vertically, one above the other, in the window. This is achieved by creating a QVBoxLayout and adding our two widgets to it, and then setting the layout on the form. If you run the application and resize it, you will find that any extra vertical space is given to the QTextBrowser, and that both widgets will grow horizontally. This is all handled automatically by the layout manager, and can be fine-tuned by setting layout policies.
One important side effect of using layouts is that PyQt automatically reparents the widgets that are laid out. So although we did not give our widgets a parent of self (the Form instance), when we call setLayout() the layout manager gives ownership of the widgets and of itself to the form, and takes ownership of any nested layouts itself. This means that none of the widgets that are laid out is a top-level window, and all of them have parents, which is what we want. So when the form is deleted, all its child widgets and layouts will be deleted with it, in the correct order.
Object Ownership
All PyQt classes that derive from QObject—and this includes all the widgets, since QWidget is a QObject subclass—can have a "parent". The parent–child relationship is used for two complementary purposes. A widget that has no parent is a top-level window, and a widget that has a parent (always another widget) is contained (displayed) within its parent. The relationship also defines ownership, with parents owning their children.
PyQt uses the parent–child ownership model to ensure that if a parent—for example, a top-level window—is deleted, all its children, for example, all the widgets the window contains, are automatically deleted as well. To avoid memory leaks, we should always make sure that any QObject, including all QWidgets, has a parent, the sole exception being top-level windows.
Most PyQt QObject subclasses have constructors that take a parent object as their last (optional) argument. But for widgets we generally do not (and need not) pass this argument. This is because widgets used in dialogs are laid out with layout managers, and when this occurs they are automatically reparented to the widget in which they are laid out, so they end up with the correct parent without requiring us to take any special action.
There are some cases where we must explicitly pass a parent—for example, when constructing QObject subclass objects that are not widgets, or that are widgets but which will not be laid out (such as dock widgets); we will see several examples of such cases in later chapters.
One final point is that it is possible to get situations where a Python variable is referring to an underlying PyQt object that no longer exists. This issue is covered in Chapter 9, in the "aliveness" discussion starting on page 287.
The widgets on a form can be laid out using a variety of techniques. We can use the resize() and move() methods to give them absolute sizes and positions; we can reimplement the resizeEvent() method and calculate their sizes and positions dynamically, or we can use PyQt's layout managers. Using absolute sizes and positions is very inconvenient. For one thing, we have to perform lots of manual calculations, and for another, if we change the layout we have to redo the calculations. Calculating the sizes and positions dynamically is a better approach, but still requires us to write quite a lot of tedious calculating code.
Using layout managers makes things a lot easier. And layout managers are quite smart: They automatically adapt to resize events and to content changes. Anyone used to dialogs in many versions of Windows will appreciate the benefits of having dialogs that can be resized (and that do so sensibly), rather than being forced to use small, nonresizable dialogs which can be very inconvenient when their contents are too large to fit. Layout managers also make life easier for internationalized programs since they adapt to content, so translated labels will not be "chopped off" if the target language is more verbose than the original language.
PyQt provides three layout managers: one for vertical layouts, one for horizontal layouts, and one for grid layouts. Layouts can be nested, so quite sophisticated layouts are possible. And there are other ways of laying out widgets, such as using splitters or tab widgets. All of these approaches are considered in more depth in Chapter 9.
As a courtesy to our users, we want the focus to start in the QLineEdit; we call setFocus() to achieve this. We must do this after setting the layout.
The connect() call is something we will look at in depth later in this chapter. Suffice it to say that every widget (and some other QObjects) announce state changes by emitting "signals". These signals (which are nothing to do with Unix signals) are usually ignored. However, we can choose to take notice of any signals we are interested in, and we do this by identifying the QObject that we want to know about, the signal it emits that we are interested in, and the function or method we want called when the signal is emitted.
So in this case, when the user presses Enter (or Return) in the QLineEdit, the returnPressed() signal will be emitted as usual, but because of our connect() call, when this occurs, our updateUi() method will be called. We will see what happens then in a moment.
The last thing we do in __init__() is set the window's title.
As we will see shortly, the form is created and show() is called on it. Once the event loop begins, the form is shown—and nothing more appears to happen. The application is simply running the event loop, waiting for the user to click the mouse or press a key. Once the user starts interacting, the results of their interaction are processed. So if the user types in an expression, the QLineEdit will take care of displaying what they type, and if they press Enter, our updateUi() method will be called.
def updateUi(self):
try:
text = unicode(self.lineedit.text())
self.browser.append("%s = <b>%s</b>" % (text, eval(text)))
except:
self.browser.append(
"<font color=red>%s is invalid!</font>" % text)
When updateUi() is called it retrieves the text from the QLineEdit, immediately converting it to a unicode object. We then use Python's eval() function to evaluate the string as an expression. If this is successful, we append a string to the QTextBrowser that has the expression text, an equals sign, and then the result in bold. Although we normally convert QStrings to unicode as soon as possible, we can pass QStrings, unicodes, and strs to PyQt methods that expect a QString, and PyQt will automatically perform any necessary conversion. If any exception occurs, we append an error message instead. Using a catch-all except block like this is not good general practice, but for a 30-line program it seems reasonable.
By using eval() we avoid all the work of parsing and error checking that we would have to do ourselves if we were using a compiled language.
app = QApplication(sys.argv) form = Form() form.show() app.exec_()
Now that we have defined our Form class, at the end of the calculate.pyw file, we create the QApplication object, instantiate an instance of our form, schedule it to be painted, and start off the event loop.
And that is the complete application. But it isn't quite the end of the story. We have not said how the user can terminate the application. Because our form derives from QDialog, it inherits some behavior. For example, if the user clicks the close button X, or if they press the Esc key, the form will close. When a form closes, it is hidden. When the form is hidden PyQt will detect that the application has no visible windows and that no further interaction is possible. It will therefore delete the form and perform a clean termination of the application.
In some cases, we want an application to continue even if it is not visible—for example, a server. For these cases, we can call QApplication.setQuitOnLastWindowClosed(False). It is also possible, although rarely necessary, to be notified when the last window is closed.
On Mac OS X, and some X Windows window managers, like twm, an application like this will not have a close button, and on the Mac, choosing Quit on the menu bar will not work. In such cases, pressing Esc will terminate the application, and in addition on the Mac, Command+. will also work. In view of this, for applications that are likely to be used on the Mac or with twm or similar, it is best to provide a Quit button. Adding buttons to dialogs is covered in this chapter's last section.
We are now ready to look at the last small, complete example that we will present in this chapter. It has more custom behavior, has a more complex layout, and does more sophisticated processing, but its fundamental structure is very similar to the Calculate application, and indeed to that of many other PyQt dialogs.