Some Notes of QT4

Part 1: Basic Qt

1. widget

In Qt and Unix terminology, a widget is a visual element in a user interface. The term stems from "window gadget" and is the equivalent of both "control" and "container" in Windows terminology. Buttons, menus, scroll bars, and frames are all examples of widgets. Widgets can contain other widgets; for example, an application window is usually a widget that contains a QMenuBar, a few QToolBars, a QStatusBar, and some other widgets. Most applications use a QMainWindow or a QDialog as the application window, but Qt is so flexible that any widget can be a window. In this example, the QLabel widget is the application window.

 

2. flicker

Widgets are always created hidden, so that we can customize them before showing them, thereby avoiding flicker.

 

3. forward declarations

For the private variables, we used forward declarations of their classes. This was possible because they are all pointers and we don't access them in the header file, so the compiler doesn't need the full class definitions. We could have included the relevant header files (<QCheckBox>, <QLabel>, etc.), but using forward declarations when it is possible makes compiling somewhat faster.

 

4. destructor

Since we used new to create the dialog's widgets and layouts, it would seem that we need to write a destructor that calls delete on each of the widgets and layouts we created. But this isn't necessary, since Qt automatically deletes child objects when the parent is destroyed, and the child widgets and layouts are all descendants of the FindDialog.

 

5. moc

For moc to work correctly, we must put the class definition in a header file, separate from the implementation file. The code generated by moc includes this header file and adds some C++ magic of its own.

 

6. double buffering

Double buffering is a GUI programming technique that consists of rendering a widget to an off-screen pixmap and copying the pixmap onto the display. With earlier versions of Qt, this technique was frequently used to eliminate flicker and to provide a snappier user interface.

In Qt 4, QWidget handles this automatically, so we rarely need to worry about widgets flickering. Still, explicit double buffering remains beneficial if the widget's rendering is complex and needed repeatedly. We can then store a pixmap permanently with the widget, always ready for the next paint event, and copy the pixmap to the widget whenever we receive a paint event. It is especially helpful when we want to do small modifications, such as drawing a rubber band, without recomputing the whole widget's rendering over and over.

 

7. Qtopia

To run Qtopia Core applications, we must first start one process to act as a server. The server is responsible for allocating screen regions to clients and for generating mouse and keyboard events. Any Qtopia Core application can become a server by specifying -qws on its command line or by passing QApplication:: GuiServer as the third parameter to the QApplication constructor.

Client applications communicate with the Qtopia Core server using shared memory. Behind the scenes, the clients draw themselves into shared memory and are responsible for painting their own window decorations. This keeps communication between the clients and the server to a minimum, resulting in a snappy user interface. Qtopia Core applications normally use QPainter to draw themselves, but they can also access the video hardware directly using QDirectPainter.

Clients can communicate with each other using the QCOP procotol. A client can listen on a named channel by creating a QCopChannel object and connecting to its received() signal.