emb-classes.html

QT 下载资料仅供参考

</h2>
<a name="7"></a><p> 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.
<p> This is used for cacheing pixmaps and allowing accelerated pixmap-&gt;screen
blt's. QLinuxFbScreen and the accelerated screens use the Linux <tt>/dev/fb</tt>
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
<tt>/dev/mem</tt>. They may also do chip-specific setup (initialising registers to
known values and so on). Finally, <a href="qscreen.html">QScreen</a>'s are used to create new
QScreenCursors and QGfxes. 
<p> 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.
<p> <h2> QScreenCursor--&gt;accelerated cursor--&gt;QVfbCursor
</h2>
<a name="8"></a><p> This handles drawing the on-screen mouse cursor, and saving and
restoring the screen under it for the non-accelerated cursor types.
<p> Subclassing QScreenCursor is optional in an accelerated driver (you
would only want to do so if the hardware supports a hardware cursor).
<p> <h2> QGfx--&gt;RasterBase--&gt;Raster--&gt;accelerated driver--&gt; QGfxVfb--&gt;QGfxTransformedRaster
</h2>
<a name="9"></a><p> This class encapsulates drawing operations, a little like a low-level
<a href="qpainter.html">QPainter</a>. 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. 
<p> 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.
<p> <h2> <a href="qlock.html">QLock</a>, QLockHolder
</h2>
<a name="10"></a><p> 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 QLocks easier. 
<p> There should be no need to modify this class unless porting
Qt/Embedded to an operating system without System V IPC.
<p> <h2> <a href="qdirectpainter.html">QDirectPainter</a>
</h2>
<a name="11"></a><p> 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 easily allow you to do your own pixel-level manipulation
of window contents. 
<p> There should be no reason to modify this class.
<p> <h2> QWSSoundServer, Client
</h2>
<a name="12"></a><p> The Qt/Embedded server contains a simple sound player and mixer. Clients
can request the server play sounds specified as files. 
<p> There should be no need to modify this class unless porting
Qt/Embedded to an operating system without a Linux-style <tt>/dev/dsp</tt>.
<p> <h2> <a href="qwswindow.html">QWSWindow</a>
</h2>
<a name="13"></a><p> 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. 
<p> There should be no reason to modify this class.
<p> <h2> <a href="qwskeyboardhandler.html">QWSKeyboardHandler</a>--&gt;subtypes
</h2>
<a name="14"></a><p> This handles keyboard/button input. QWSKeyboardHandler is subclassed
to provide for reading <tt>/dev/tty</tt>, an arbitrary low-level USB event device
(for USB keyboards) and some PDA button devices. 
<p> 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.
<p> <h2> <a href="qwsmousehandler.html">QWSMouseHandler</a>--&gt;QCalibratedMouseHandler--&gt;mouse types
</h2>
<a name="15"></a><p> This handles mouse/touchpanel 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.
<p> Subclassing QCalibratedMouseHandler is preferred for touchpanels without
kernel filtering; inheriting QWSMouseHandler is the way to add any other
type of pointing device (pen tablets, touchscreens, mice, trackballs
and so forth).
<p> <h2> QWSDisplay
</h2>
<a name="16"></a><p> 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.
<p> You would only want to modify this if making deep and drastic
modifications to Qt/Embedded window behaviour (alpha blended windows
for example).
<p> <h2> <a href="qwsserver.html">QWSServer</a> 
</h2>
<a name="17"></a><p> 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.
<p> 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/QWSServerSocket
instead. Don't add extra QWS events to communicate between
applications, use QCOP instead.
<p> <h2> QWSClient
</h2>
<a name="18"></a><p> This encapsulates the client side of a Qt/Embedded connection and can
marshal and demarshal events. 
<p> There should be no reason to modify this except to use something
radically different from Unix domain sockets to communicate between
Qt/Embedded applications.
<p> <h2> QWSDisplayData
</h2>
<a name="19"></a><p> 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 <tt>/dev/fb</tt> in QLinuxFbScreen. 
<p> There should be no reason to modify this.
<p> <h2> QWSCommands
</h2>
<a name="20"></a><p> These encapsulate the data sent to and from the QWS server. 
<p> There should be no reason to modify them.
<p> <h2> <a href="qcopchannel.html">QCopChannel</a>
</h2>
<a name="21"></a><p> QCop is a simple IPC mechanism for communication between Qt/Embedded
applications. String messages with optional binary data can be sent
to different channels. 
<p> The mechanism itself is designed to be bare-bones in order for users
to build whatever mechanism they like on top of it.
<p> <h2> QWSManager
</h2>
<a name="22"></a><p> This provides Qt/Embedded window management, drawing a title bar
and handling user requests to move, resize the window and so on.
<p> There should be no reason to modify it but you should subclass it
if you want to modify window behaviour (point to click versus
focus follows mouse, for instance).
<p> <h2> <a href="qwsdecoration.html">QWSDecoration</a>
</h2>
<a name="23"></a><p> 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. 
<p> Subclass it in order to provide a new window manager appearance (the
equivalent of a Windows XP or Enlightenment theme).
<p> <h2> QWSPropertyManager
</h2>
<a name="24"></a><p> 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). 
<p> There should be no reason to modify it.
<p> <h2> QWSRegionManager
</h2>
<a name="25"></a><p> Used by both client and server to help manage top-level window regions.
<p> There should be no reason to modify it.
<p> <h2> QWSSocket, QWSServerSocket
</h2>
<a name="26"></a><p> Provides Unix-domain sockets. 
<p> 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).
<p> 
<!-- eof -->
<p><address><hr><div align=center>
<table width=100% cellspacing=0 border=0><tr>
<td>Copyright &copy; 2002 
<a href="http://www.trolltech.com">Trolltech</a><td><a href="http://www.trolltech.com/trademarks.html">Trademarks</a>
<td align=right><div align=right>Qt version 3.0.5</div>
</table></div></address></body>
</html>