Understanding the steps involved in a process in just the first step in the journey of understanding the process. In the first part of PyQT, the first step in understanding the process of building a GUI using PyQT was taken. The journey has just begun.

In this journey we will be encountering various components starting with the most common widgets (windows, buttons, etc.) and moving on to exquisite widgets (table view, 3d canvas). In this discussion I will be focusing on the most common  ones that become the foundation of a GUI based application: the window and button. In the vocabulary of PyQT they are termed as QWindow (QDialog, QMainWindow, and so on also serve this purpose) and QButton (QPushButton, QRadioButton, and so forth).

In the first section, I will be discussing QDialog. Then I will cover the main slots and signals of QDialog. In the third section I will discuss QPushButton. Finally, in the last section I will extend the application developed in the previous part to provide the functionalities of changing the display to binary mode, as well as controlling the application window using buttons. That sets the agenda for this discussion.

QDialog and QPushButton: Gateways to PyQT Applications

Dialogs and buttons are the most recognized facets of GUI. So how can a toolkit like PyQT be behind? As with all other widgets, it is necessary to know the details in order to tap into their full power. So here are the details.

First, let's discuss the QDialog class. As you know, windows form the basis of all the GUI-based applications. However there are windows and windows. There is a category of windows that acts as containers for other windows and widgets, such as menus and so on. Then there is a category that acts as a container for simple widgets, and is used for capturing user inputs for a specific process.

The first category contains the Main Window of an application, and the second category contains the dialog boxes. Though dialog boxes are primarily used to gather user inputs, there are applications that are built completely upon dialog boxes. In this section I will be discussing the attributes, signals and slots that are required more often in building a dialog based application.

Dialog, by definition, is a window that pops up over the existing application window. The QDialog class is the parent of all the dialog classes. If you remember the "Hello World" application from the first part, the class was derived from QDialog. Now coming back to the QDialog class, it effectively represents the dialogs of real world user interfaces. Since there are two types of dialogs in real world, so the QDialog also supports two types of dialogs, modal and modeless. The important aspect of any type of dialog is that even though it is top level widget, yet it can have a parent.

Now, let's discuss modal dialogues. If a dialog blocks input to the other widgets, then it is modal.  The most common way to make a dialog modal is by calling its exec_loop() method. The exec_loop() method returns a useful value when the dialog is closed. One other approach is to call the setModal() method with true. But this has to be done before calling the show() method, because once show() is called, setModal() wont have any effect.

For example, if mDialog is an object of the MDialog class that is derived from QDialog, then:

    mDialog.setModal(true)
  mDialog.show()

    and

    mDialog.exec_loop()

    perform the same function. That is both methods makes the dialog modal.

As for a modeless dialogue, its functioning is opposite to that of a modal dialog. The best examples of modeless dialog boxes are search/replace dialogs provided by word processors. Dialogs are made modeless by calling the show() method instead of the QDialog class. The show() method doesn't grab the focus from other window elements. Instead it returns to the caller immediately.