The characteristic feature of any scripting language, including Python, is that it don’t have a native GUI interface. But this has, in a way, become an advantage. Any existing GUI toolkit can be wrapped up and used as a binding for the language. This is exactly what Phil Thompson did when he wrapped QT, thus producing PyQT. In essence, PyQT is still has QT as its foundation. Hence understanding the basics and terminology of QT must come first. The most obvious question from the uninitiated is, what is QT? That’s where I am going to begin.

What is QT?

By definition QT is “a multi-platform C++ application framework which can be used by developers to write single-source applications capable of running natively on Windows, Linux, UNIX, Mac OS X and embedded Linux.” In short, it means write once, compile anywhere. The reason for this is that QT APIs are the same for all platforms and produce native executables.

This brings out another point. Doesn’t Java promise the same thing? There is a big difference. Java achieves platform independence by means of a Virtual Machine, whereas in the case of QT, the source needs to be compiled for each of the target platforms. This helps keep it lightweight and significantly faster. 

Now that you know what QT is, the next important issue is understanding the types of Objects available on QT. There are two kinds of objects in QT, Visual Objects and Non-visual Objects.

Visual Objects includes menus, buttons, icons and so on. They are also known as Widgets. From here onwards  I will be referring to the Visual Objects as Widgets. All the Widgets are form objects.

Non-visual Objects are objects apart from Widgets that provide service but don’t have any visible shape, size or such properties. Timers, painters etc. form a part of such objects. Though, they don’t "exhibit" any visual properties, they are used on a par with Widgets. Timer (or QTimer) is the best example. It is not visible at runtime but almost all the multi-threaded applications use QTimer for their workings.

In a discussion on PyQT and for that matter QT, two terms figure prominently: Signals and Slots. These two represent the even-driven paradigm in the world of QT (and PyQT). I explain them in the next two paragraphs.

Signals are emitted by an object when its state changes. In other words, Signals are events that are generated when the internal properties of an object change. Whenever a Signal is emitted, the connected Slot is executed automatically, which is just like calling a function. The execution of Slots is independent of the GUI event loop. If a number of Slots are connected with a Signal, on the emitting of the Signals, these Slots are executed in an arbitrary manner.

Slots are simple functions that are called when a Signal is emitted. Though a Slot is a simple function, one feature makes it special: it can be connected to a signal. In other words, a Slot is a callback function. A Slot can be public, private, protected and even virtual (in terms of QT). The relationship between Signals and Slots is many-to-many.

That’s all there is to understand about the basic terminology of QT and PyQT. The next step is to understand how QT is mapped with PyQT. The best way to understand this is to understand the steps involved in creating a PyQT application. That is what next segment is about.