HomeHome

The Qt/Embedded-specific classes


Introduction

Qt/Embedded classes fall into two classes - the majority are used by every Qt/Embedded program, some are used only by the Qt/Embedded server. The Qt/Embedded server program can be a client as well, as in the case of a single-process installation. All Qt/Embedded specific source files live in src/kernel and are suffixed _qws. -> indicates inheritance.

Client classes

QFontManager

There is one of these per application. At application startup time it reads the font definition file from $QTDIR/etc/fonts/fontdir (or /usr/local/etc/qt-embedded/fonts/fontdir if QTDIR is undefined). It keeps track of all font information and holds a cache of rendered fonts. It also creates the font factories - QFontManager::QFontManager is the place to add constructors for new factories. It provides a high-level interface to requesting a particular font and calls QFontFactories to load fonts from disk on demand. Note that this only applies to BDF and Truetype fonts; Qt/Embedded's optimised .qpf font file format bypasses the QFontManager mechanism altogether.

QDiskFont

This contains information about a single on-disk font file (e.g. /usr/local/etc/qt-embedded/times.ttf, would be an example). It holds the file path, information about whether the font is scalable, its weight, size and Qt/Embedded name and so on. This information is used so that QFontManager can find the closest match disk font (it uses a scoring mechanism weighted towards matching names, then whether the font's italic, then weight)

QRenderedFont

There is one and only one QRenderedFont for every unique font currently loaded by the system (that is, each unique combination of name, size, weight, italic or not, anti-aliased or not) QRenderedFonts are reference counted; once noone is using the QRenderedFont it is deleted along with its cache of glyph bitmaps. The QDiskFont it was loaded from remains opened by its QFontFactory however.

QFontFactory derrived classes

QFontFactory derrived classes provide support for particular font formats, for instance the scalable Truetype and Type1 formats (both supported in QFontFactoryTtf, which uses Freetype 2) and the bitmap BDF format used by X. It's called to open an on-disk font; once a font is opened it remains opened, for quickness in creating new font instances from the disk font. It can also create a QRenderedFont and convert from unicode values to an index into the font file - glyphs are stored in the order and indexes they are defined in the font rather than in unicode order for compactness.

QGlyph

This describes a particular image of a character from a QRenderedFont - for example, the letter 'A' at 10 points in Times New Roman, bold italic, anti-aliased. It contains pointers to a QGlyphMetrics structure with information about the character and to the raw data for the glyph - this is either a 1-bit mask or an 8-bit alpha channel. Each QRenderedFont creates these on demand and caches them once created (note that this is not currently implemented for Truetype fonts)

QMemoryManagerPixmap and QMemoryManager

QMemoryManagerPixmap and QMemoryManager handles requests for space for pixmaps and also keeps track of QPF format fonts (these are small 'state dumps' of QRenderedFonts, typically 2-20k in size; they can be mmap'd direct from disk in order to save memory usage). If a QPF font is found which matches a font request no new QRenderedFont need be created for it. It's possible to strip out all QFontFactory support and simply use QPFs if your font needs are modest (for instance, if you only require a few fixed point sizes). Note that no best-match loading is performed with QPFs, as opposed to those loaded via QFontManager, so if you don't have the correct QPF for a point size text in that size will simply not be displayed.

QScreen derrived classes

QScreen -> QLinuxFbScreen -> accelerated screens

QTransformedScreen -> QVfbScreen

These encapsulate the framebuffer Qt/Embedded is drawing to, provide support for mapping of coordinates for rotating framebuffers, allow manipulation of the colour palette and provide access to offscreen graphics memory for devices with separate framebuffer memories. This is used for cacheing pixmaps and allowing accelerated pixmap->screen blt's. QLinuxFbScreen and the accelerated screens use the Linux /dev/fb interface to get access to graphics memory and information about the characteristics of the device. The framebuffer device to open is specified by QWS_DISPLAY. Only QTransformedScreen implements the support for rotated framebuffers. QVfbScreen provides an X window containing an emulated framebuffer (a chunk of shared memory is set aside as the 'framebuffer' and blt'd into the X window) - this is intended as a debugging device allowing users to debug their applications under Qt/Embedded without leaving X. The accelerated screen drivers check to see if they can drive the device specified by QWS_CARD_SLOT (which defaults to the usual position of an AGP slot if not specified) and mmap its on-chip registers from /dev/mem. They may also do chip-specific setup (initialising registers to known values and so on). Finally, QScreen's are used to create new QScreenCursors and QGfxes.

QScreenCursor derrived classes

QScreenCursor -> accelerated cursor
              -> QVfbCursor

QScreenCursor derrived classes handles drawing the on-screen mouse cursor, saving and restoring the screen under it for the non-accelerated cursor types.

QGfx derrived classes

QGfx -> RasterBase -> Raster -> accelerated driver
                             -> QGfxVfb
                             -> QGfxTransformedRaster

This class encapsulates drawing operations, a little like a low-level QPainter. QGfxRaster and its descendants are specifically intended for drawing into a raw framebuffer. They can take an offset for drawing operations and a clipping region in order to support drawing into windows.

QLock and QLockHolder

QLock and QLockHolder encapsulates a System V semaphore, used for synchronising access to memory shared between Qt/Embedded clients. QLockHolder is a utility class to make managing and destroying QLocks easier.

QDirectPainter

QDirectPainter is QPainter which also gives you a pointer to the framebuffer of the window it's pointing to, the window's clip region and so on. It's intended to easily allow you to do your own pixel-level manipulation of window contents.

QWSSoundServer and QWSSoundClient

The Qt/Embedded server contains a simple sound player and mixer. Clients can request the server play sounds specified as files.

QWSWindow

QWSWindow contains the server's notion of an individual top level window - the region of the framebuffer it's allocated, the client that created it and so forth

QWSKeyboardHandler derrived classes

This handles keyboard/button input. QWSKeyboardHandler is subclassed to provide for reading /dev/tty, an arbitrary low-level USB event device (for USB keyboards) and some PDA button devices.

QWSMouseHandler derrived classes

    QWSMouseHandler->QCalibratedMouseHandler->mouse types
                   ->mouse types

This handles mouse/touchpanel input. Descendants of QCalibratedMouseHandler make use of filtering code which pretends 'jittering' of the pointer on touchscreens; some embedded devices do this filtering in the kernel in which case the driver doesn't need to inherit from QCalibratedMouseHandler.

QWSDisplay

QWSDisplay class exists only in the Qt/Embedded server and keeps track of all the top-level windows in the system, as well as the keyboard and mouse.

QWSServer

QWSServer manages the Qt/Embedded server's Unix-domain socket connections to clients. It sends and receives QWS protocol events and calls QWSDisplay in order to do such things as change the allocation region of windows.

QWSClient

QWSClient encapsulates the client side of a Qt/Embedded connection and can marshal and demarshal events.

QWSDisplayData

QWSDisplayData manages a client's QWSClient, reading and interpreting events from the QWS server. It connects to the QWS server on application startup, getting information about the framebuffer and creating the memory manager. Other information about the framebuffer comes directly from /dev/fb in QLinuxFbScreen.

QWSCommands

QWSCommands encapsulate the data sent to and from the QWS server

QCopChannel

QCopChannel provides QCop; which is a simple IPC mechanism for communication between Qt/Embedded applications. String messages with optional binary data can be sent to different channels.

QWSManager

QWSManager provides Qt/Embedded window management, drawing a title bar and handling user requests to move, resize the window and so on.

QWSDecoration derrived classes

Descendants of the QWSDecoration class are different styles for the Qt/Embedded window manager, for instance QWSWindowsDecoration draws Qt/Embedded window frames in the style of Windows CE.

QWSPropertyManager

QWSPropertyManager provides the QWS client's interface to the QWS property system (a simpler version of the X property system, it allows you to attach arbitrary data to top-level windows, keyed by an integer)

QWSRegionManager

QWSRegionManager is by both client and server to help manage top-level window regions

QWSSocket and QWSServerSocket

QWSSocket and QWSServerSocket provide Unix-domain sockets


Copyright © 2005 TrolltechTrademarks
Qt version 2.3.10-snapshot-20060120