|
|
              
Simple Decoration ExampleThe Simple Decoration example shows how to create a custom window decoration for embedded applications.
By default, Qt for Embedded Linux applications display windows with one of the standard window decorations provided by Qt which are perfectly suitable for many situations. Nonetheless, for certain applications and devices, it is necessary to provide custom window decorations. In this document, we examine the fundamental features of custom window decorations, and create a simple decoration as an example. Styles and Window DecorationsOn many platforms, the style used for the contents of a window (including scroll bars) and the style used for the window decorations (the title bar, window borders, close, maximize and other buttons) are handled differently. This is usually because each application is responsible for rendering the contents of its own windows and the window manager renders the window decorations. Although the situation is not quite like this on Qt for Embedded Linux because QApplication automatically handles window decorations as well, there are still two style mechanisms at work: QStyle and its associated classes are responsible for rendering widgets and subclasses of QDecoration are responsible for rendering window decorations.
Three decorations are provided with Qt for Embedded Linux: default is a basic style, windows resembles the classic Windows look and feel, and styled uses the QStyle classes for QMdiSubWindow to draw window decorations. Of these, styled is the most useful if you want to impose a consistent look and feel, but the window decorations may be too large for some use cases. If none of these built-in decorations are suitable, a custom style can easily be created and used. To do this, we simply need to create a subclass of QDecorationDefault and apply it to a QApplication instance in a running application. MyDecoration Class DefinitionThe MyDecoration class is a subclass of QDecorationDefault, a subclass of QDecoration that provides reasonable default behavior for a decoration: We only need to implement a constructor and reimplement the region() and paint() functions to provide our own custom appearance for window decorations. To make things fairly general, we provide a number of private variables to hold parameters which control certain aspects of the decoration's appearance. We also define some data structures that we will use to relate buttons in the window decorations to regions. MyDecoration Class ImplementationIn the constructor of the MyDecoration class, we set up some default values for the decoration, specifying a thin window border, a title bar that is just taller than the buttons it will hold, and we create a list of buttons that we support: We map each of these Qt::WindowFlags to QDecoration::DecorationRegion enum values to help with the implementation of the region() function implementation. In this decoration, we implement the buttons used in the decoration as pixmaps. To help us relate regions of the window to these, we define mappings between each DecorationRegion and its corresponding pixmap for two situations: when a window is shown normally and when it has been maximized. This is purely for cosmetic purposes. We finish the constructor by defining the regions for buttons that we understand. This will be useful when we are asked to give regions for window decoration buttons. Finding RegionsEach decoration needs to be able to describe the regions used for parts of the window furniture, such as the close button, window borders and title bar. We reimplement the region() function to do this for our decoration. This function returns a QRegion object that describes an arbitrarily-shaped region of the screen that can itself be made up of several distinct areas. The function is called for a given widget, occupying a region specified by insideRect, and is expected to return a region for the collection of DecorationRegion enum values supplied in the decorationRegion parameter. We begin by figuring out how much space in the decoration we will need to allocate for buttons, and where to place them: In a more sophisticated implementation, we might test the decorationRegion supplied for regions related to buttons and the title bar, and only perform this space allocation if asked for regions related to these. We also use the information about the area occupied by buttons to determine how large an area we can use for the window title: With these basic calculations done, we can start to compose a region, first checking whether we have been asked for all of the window, and we return immediately if so. We examine each decoration region in turn, adding the corresponding region to the region object created earlier. We take care to avoid "off by one" errors in the coordinate calculations. Unlike the window borders and title bar, the regions occupied by buttons many of the window decorations do not occupy fixed places in the window. Instead, their locations depend on which other buttons are present. We only add regions for buttons we can handle (defined in the stateRegions) member variable, and only for those that are present (defined in the buttons hash). The fully composed region can then be returned: The information returned by this function is used when the decoration is painted. Ideally, this function should be implemented to perform all the calculations necessary to place elements of the decoration; this makes the implementation of the paint() function much easier. Painting the DecorationThe paint() function is responsible for drawing each window element for a given widget. Information about the decoration region, its state and the widget itself is provided along with a QPainter object to use. The first check we make is for a call with no regions: We return false to indicate that we have not painted anything. If we paint something, we must return true so that the window can be composed, if necessary. Just as with the region() function, we test the decoration region to determine which elements need to be drawn. If we paint anything, we set the handled variable to true so that we can return the correct value when we have finished. Note that we use our own region() implementation to determine where to draw decorations. Since the region() function performs calculations to place buttons, we can simply test the window flags against the buttons we support (using the buttonHintMap defined in the constructor), and draw each button in the relevant region: Finally, we return the value of handled to indicate whether any painting was performed: We now have a decoration class that we can use in an application. Using the DecorationIn the main.cpp file, we set up the application as usual, but we also create an instance of our decoration and set it as the standard decoration for the application: This causes all windows opened by this application to use our decoration. To demonstrate this, we show the analog clock widget from the Analog Clock Example, which we build into the application: The application can be run either as a server or a client application. In both cases, it will use our decoration rather than the default one provided with Qt. NotesThis example does not cache any information about the state or buttons used for each window. This means that the region() function calculates the locations and regions of buttons in cases where it could re-use existing information. If you run the application as a window server, you may expect client applications to use our decoration in preference to the default Qt decoration. However, it is up to each application to draw its own decoration, so this will not happen automatically. One way to achieve this is to compile the decoration with each application that needs it; another way is to build the decoration as a plugin, using the QDecorationPlugin class, and load it into the server and client applications. |
