Home | All Classes | Main Classes | Annotated | Grouped Classes | Functions |

# The Qt/Embedded-Specific Classes

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

- QMemoryManagerPixmap/QMemoryManager
- QScreen > QLinuxFbScreen > accelerated screens, QTransformedScreen > QVfbScreen
- QScreenCursor > accelerated cursor > QVfbCursor
- QGfx > RasterBase > Raster > accelerated driver > QGfxVfb > QGfxTransformedRaster
- QLock, QLockHolder
- QDirectPainter
- QWSSoundServer, Client
- QWSWindow
- QWSKeyboardHandler > subtypes
- QWSMouseHandler > QCalibratedMouseHandler > mouse types
- QWSDisplay
- QWSServer
- QWSClient
- QWSDisplayData
- QWSCommands
- QCopChannel
- QWSManager
- QWSDecoration
- QWSPropertyManager
- QWSRegionManager
- QWSSocket, QWSServerSocket

## QMemoryManagerPixmap/QMemoryManager

This handles requests for space for pixmaps.

There should be no need to modify this class.

## 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 caching pixmaps and allowing accelerated pixmap-to-screen bit block transfers (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 `QGfx`es.

If you wish to modify the way pixmaps are allocated in memory, subclass or modify `QLinuxFbScreen`. If you're writing an accelerated driver you will need to subclass `QScreen` or `QLinuxFbScreen`.

## QScreenCursor > accelerated cursor > QVfbCursor

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

Subclassing `QScreenCursor` is optional in an accelerated driver (you would only want to do so if the hardware supports a hardware cursor).

## 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. You will need to subclass the `QGfxRaster` template in order to implement an accelerated driver.

If you're brave, modifying `QGfxRaster` would allow you to customise how drawing is done or add support for a new bit depth/pixel format.

## QLock, QLockHolder

This 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 `QLock`s easier.

There should be no need to modify this class unless porting Qt/Embedded to an operating system without System V IPC.

## QDirectPainter

This is a `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 allow you to easily do your own pixel-level manipulation of window contents.

There should be no reason to modify this class.

## QWSSoundServer, Client

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

There should be no need to modify this class unless porting Qt/Embedded to an operating system without a Linux-style `/dev/dsp`.

## QWSWindow

This 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.

There should be no reason to modify this class.

## QWSKeyboardHandler > subtypes

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.

Modifying `QWSKeyboardHandler` would allow you to support different types of keyboard (currently only a fairly standard US PC style keyboard is supported); subclassing it is the preferred way to handle non-pointer input devices.

## QWSMouseHandler > QCalibratedMouseHandler > mouse types

This handles mouse/touch-panel input. Descendants of `QCalibratedMouseHandler` make use of filtering code which prevents '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`.

Subclassing `QCalibratedMouseHandler` is preferred for touch-panels without kernel filtering; inheriting `QWSMouseHandler` is the way to add any other type of pointing device (pen tablets, touchscreens, mice, trackballs and so forth).

## QWSDisplay

This 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.

You would only want to modify this if making deep and drastic modifications to Qt/Embedded window behavior (alpha blended windows for example).

## QWSServer

This 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.

The only reason to modify this would be to use something other than some sort of socket-like mechanism to communicate between Qt/Embedded applications (in which case modify `QWSClient` too). If you have something like Unix domain sockets, modify `QWSSocket/\c` QWSServerSocket instead. Don't add extra QWS events to communicate between applications, use `QCop` instead.

## QWSClient

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

There should be no reason to modify this except to use something radically different from Unix domain sockets to communicate between Qt/Embedded applications.

## QWSDisplayData

This 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`.

There should be no reason to modify this class.

## QWSCommands

These encapsulate the data sent to and from the QWS server.

There should be no reason to modify them.

## QCopChannel

`QCop` is a simple inter-process communication (IPC) mechanism for communication between Qt/Embedded applications. String messages with optional binary data can be sent to different channels.

The mechanism itself is designed to be bare-bones in order for users to build whatever higher-level layer they like on top of it.

## QWSManager

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

There should be no reason to modify it but you should subclass it if you want to modify window behavior (point to click versus focus follows mouse, for instance).

## QWSDecoration

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

Subclass it in order to provide a new window manager appearance (the equivalent of a Windows XP or Enlightenment theme).

## QWSPropertyManager

This 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).

There should be no reason to modify this class.

## QWSRegionManager

Used by both client and server to help manage top-level window regions.

There should be no reason to modify this class.

## QWSSocket, QWSServerSocket

Provides Unix-domain sockets.

Modify this if you're porting to a non-Unix OS but have something analogous to Unix-domain sockets (a byte-oriented, reliable, ordered transmission mechanism, although you can probably implement it with something like a message queue as well).