You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
340 lines
17 KiB
340 lines
17 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<!-- /home/espenr/tmp/qt-3.3.8-espenr-2499/qt-x11-free-3.3.8/doc/embclasses.doc:36 -->
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|
<title>The TQt/Embedded-specific classes</title>
|
|
<style type="text/css"><!--
|
|
fn { margin-left: 1cm; text-indent: -1cm; }
|
|
a:link { color: #004faf; text-decoration: none }
|
|
a:visited { color: #672967; text-decoration: none }
|
|
body { background: #ffffff; color: black; }
|
|
--></style>
|
|
</head>
|
|
<body>
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
<tr bgcolor="#E5E5E5">
|
|
<td valign=center>
|
|
<a href="index.html">
|
|
<font color="#004faf">Home</font></a>
|
|
| <a href="classes.html">
|
|
<font color="#004faf">All Classes</font></a>
|
|
| <a href="mainclasses.html">
|
|
<font color="#004faf">Main Classes</font></a>
|
|
| <a href="annotated.html">
|
|
<font color="#004faf">Annotated</font></a>
|
|
| <a href="groups.html">
|
|
<font color="#004faf">Grouped Classes</font></a>
|
|
| <a href="functions.html">
|
|
<font color="#004faf">Functions</font></a>
|
|
</td>
|
|
<td align="right" valign="center"><img src="logo32.png" align="right" width="64" height="32" border="0"></td></tr></table><h1 align=center>The TQt/Embedded-specific classes</h1>
|
|
|
|
|
|
|
|
<p> TQt/Embedded classes fall into two groups: the majority are used by
|
|
every TQt/Embedded program, and some are used only by the TQt/Embedded server.
|
|
The TQt/Embedded server program can also be a client, as in the case of a
|
|
single-process installation. All TQt/Embedded specific source files live
|
|
in <tt>src/kernel</tt> and are suffixed <tt>_qws</tt>. The » symbol
|
|
indicates inheritance.
|
|
<p> <!-- toc -->
|
|
<ul>
|
|
<li><a href="#1"> TQFontManager
|
|
</a>
|
|
<li><a href="#2"> TQDiskFont
|
|
</a>
|
|
<li><a href="#3"> TQRenderedFont
|
|
</a>
|
|
<li><a href="#4"> TQFontFactory (and descendants TQFontFactoryBDF, TQFontFactoryTtf)
|
|
</a>
|
|
<li><a href="#5"> TQGlyph
|
|
</a>
|
|
<li><a href="#6"> TQMemoryManagerPixmap/TQMemoryManager
|
|
</a>
|
|
<li><a href="#7"> TQScreen » TQLinuxFbScreen » accelerated screens, TQTransformedScreen » TQVfbScreen
|
|
</a>
|
|
<li><a href="#8"> TQScreenCursor » accelerated cursor » TQVfbCursor
|
|
</a>
|
|
<li><a href="#9"> TQGfx » RasterBase » Raster » accelerated driver » TQGfxVfb » TQGfxTransformedRaster
|
|
</a>
|
|
<li><a href="#10"> TQLock, TQLockHolder
|
|
</a>
|
|
<li><a href="#11"> TQDirectPainter
|
|
</a>
|
|
<li><a href="#12"> TQWSSoundServer, Client
|
|
</a>
|
|
<li><a href="#13"> TQWSWindow
|
|
</a>
|
|
<li><a href="#14"> TQWSKeyboardHandler » subtypes
|
|
</a>
|
|
<li><a href="#15"> TQWSMouseHandler » TQWSCalibratedMouseHandler » mouse types
|
|
</a>
|
|
<li><a href="#16"> TQWSDisplay
|
|
</a>
|
|
<li><a href="#17"> TQWSServer
|
|
</a>
|
|
<li><a href="#18"> TQWSClient
|
|
</a>
|
|
<li><a href="#19"> TQWSDisplayData
|
|
</a>
|
|
<li><a href="#20"> TQWSCommands
|
|
</a>
|
|
<li><a href="#21"> TQCopChannel
|
|
</a>
|
|
<li><a href="#22"> TQWSManager
|
|
</a>
|
|
<li><a href="#23"> TQWSDecoration
|
|
</a>
|
|
<li><a href="#24"> TQWSPropertyManager
|
|
</a>
|
|
<li><a href="#25"> TQWSRegionManager
|
|
</a>
|
|
<li><a href="#26"> TQWSSocket, TQWSServerSocket
|
|
</a>
|
|
</ul>
|
|
<!-- endtoc -->
|
|
|
|
<p> <h2> <a href="qfontmanager.html">TQFontManager</a>
|
|
</h2>
|
|
<a name="1"></a><p> There is one of these per application. At application startup time it
|
|
reads the font definition file from <tt>$TQTDIR/etc/fonts/fontdir</tt> (or <tt>/usr/local/etc/qt-embedded/fonts/fontdir</tt> if TQTDIR is undefined). It
|
|
keeps track of all font information and maintains a cache of rendered
|
|
fonts. It also creates the font factories: TQFontManager::TQFontManager
|
|
is the place to add constructors for new factories. It provides a
|
|
high-level interface for requesting a particular font and calls
|
|
TQFontFactories to load fonts from disk on demand. Note that this only
|
|
applies to BDF and TrueType fonts; TQt/Embedded's optimised <tt>.qpf</tt>
|
|
font file format bypasses the TQFontManager mechanism altogether.
|
|
<p> There should be no need to modify this class unless you wish to change
|
|
font matching or caching behaviour.
|
|
<p> <h2> TQDiskFont
|
|
</h2>
|
|
<a name="2"></a><p> This contains information about a single on-disk font file (e.g.
|
|
<tt>/usr/local/etc/qt-embedded/times.ttf</tt>). It holds the file path,
|
|
information about whether the font is scalable, its weight, size,
|
|
TQt/Embedded name, etc. This information is used so that <a href="qfontmanager.html">TQFontManager</a>
|
|
can find the closest matching disk font (it uses a scoring mechanism
|
|
weighted towards matching names, then whether the font's italic, then
|
|
its weight).
|
|
<p> There should be no reason to modify this class.
|
|
<p> <h2> TQRenderedFont
|
|
</h2>
|
|
<a name="3"></a><p> There is one and only one TQRenderedFont 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).
|
|
TQRenderedFonts are reference counted; once no one is using the
|
|
TQRenderedFont it is deleted along with its cache of glyph bitmaps. The
|
|
TQDiskFont it was loaded from remains opened by its TQFontFactory.
|
|
<p> There should be no reason to modify this class, unless you wish to
|
|
change the way in which glyphs are cached.
|
|
<p> <h2> TQFontFactory (and descendants TQFontFactoryBDF, TQFontFactoryTtf)
|
|
</h2>
|
|
<a name="4"></a><p> These provide support for particular font formats, for instance the
|
|
scalable Truetype and Type1 formats (both supported in
|
|
TQFontFactoryTtf, 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 so that the creation of new font instances from the
|
|
disk font is fast. It can also create a TQRenderedFont and convert from
|
|
Unicode values to an index into the font file. For compactness, glyphs
|
|
are stored in the order and indexes they are defined in the font
|
|
rather than in Unicode order.
|
|
<p> There should be no need to modify this class, but it should be
|
|
inherited if you wish to add a different type of font renderer (e.g.
|
|
for a custom vector font format).
|
|
<p> <h2> TQGlyph
|
|
</h2>
|
|
<a name="5"></a><p> This describes a particular image of a character from a TQRenderedFont:
|
|
for example, the letter 'A' at 10 points in Times New Roman, bold italic,
|
|
anti-aliased. It contains pointers to a TQGlyphMetrics 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 TQRenderedFont
|
|
creates these on demand and caches them once created (note that this is
|
|
not currently implemented for TrueType fonts).
|
|
<p> You would only need to modify this class if you were, for example,
|
|
modifying TQt/Embedded to support textured fonts, in which case you
|
|
would also need to modify TQGfxRaster.
|
|
<p> <h2> TQMemoryManagerPixmap/TQMemoryManager
|
|
</h2>
|
|
<a name="6"></a><p> This handles requests for space for pixmaps and also keeps track of
|
|
TQPF format fonts (these are small 'state dumps' of TQRenderedFonts,
|
|
typically 2-20KB in size; they can be mmap'd direct from disk in order
|
|
to save memory). If a TQPF font is found which matches a font request
|
|
no new TQRenderedFont need be created for it. It's possible to strip out
|
|
all TQFontFactory support and simply use TQPFs 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 TQPFs, as opposed to those
|
|
loaded via <a href="qfontmanager.html">TQFontManager</a>, so if you don't have the correct TQPF for a point
|
|
size, text in that size will simply not be displayed.
|
|
<p> There should be no need to modify this class.
|
|
<p> <h2> <a href="qscreen.html">TQScreen</a> » TQLinuxFbScreen » accelerated screens, TQTransformedScreen » TQVfbScreen
|
|
</h2>
|
|
<a name="7"></a><p> These encapsulate the framebuffer TQt/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 caching pixmaps and allowing accelerated pixmap=>screen
|
|
blt's. TQLinuxFbScreen 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 TQWS_DISPLAY. Only TQTransformedScreen implements the support for rotated
|
|
framebuffers. TQVfbScreen 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 TQt/Embedded without leaving
|
|
X. The accelerated screen drivers check to see if they can drive the
|
|
device specified by TQWS_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">TQScreen</a>'s are used to create new
|
|
TQScreenCursors and TQGfxes.
|
|
<p> If you wish to modify the way pixmaps are allocated in memory,
|
|
subclass or modify TQLinuxFbScreen. If you're writing an accelerated
|
|
driver you will need to subclass TQScreen or TQLinuxFbScreen.
|
|
<p> <h2> TQScreenCursor » accelerated cursor » TQVfbCursor
|
|
</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 TQScreenCursor is optional in an accelerated driver (you
|
|
would only want to do so if the hardware supports a hardware cursor).
|
|
<p> <h2> TQGfx » RasterBase » Raster » accelerated driver » TQGfxVfb » TQGfxTransformedRaster
|
|
</h2>
|
|
<a name="9"></a><p> This class encapsulates drawing operations, a little like a low-level
|
|
<a href="ntqpainter.html">TQPainter</a>. TQGfxRaster 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 TQGfxRaster template in order to implement
|
|
an accelerated driver.
|
|
<p> If you're brave, modifying TQGfxRaster would allow you to customise how
|
|
drawing is done or add support for a new bit depth/pixel format.
|
|
<p> <h2> TQLock, TQLockHolder
|
|
</h2>
|
|
<a name="10"></a><p> This encapsulates a System V semaphore, used for synchronising access
|
|
to memory shared between TQt/Embedded clients. TQLockHolder is a utility class
|
|
to make managing and destroying TQLocks easier.
|
|
<p> There should be no need to modify this class unless porting
|
|
TQt/Embedded to an operating system without System V IPC.
|
|
<p> <h2> <a href="qdirectpainter.html">TQDirectPainter</a>
|
|
</h2>
|
|
<a name="11"></a><p> This is a TQPainter 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> TQWSSoundServer, Client
|
|
</h2>
|
|
<a name="12"></a><p> The TQt/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
|
|
TQt/Embedded to an operating system without a Linux-style <tt>/dev/dsp</tt>.
|
|
<p> <h2> <a href="qwswindow.html">TQWSWindow</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">TQWSKeyboardHandler</a> » subtypes
|
|
</h2>
|
|
<a name="14"></a><p> This handles keyboard/button input. TQWSKeyboardHandler 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 TQWSKeyboardHandler 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">TQWSMouseHandler</a> » TQWSCalibratedMouseHandler » mouse types
|
|
</h2>
|
|
<a name="15"></a><p> This handles mouse/touch-panel input. Descendants of TQWSCalibratedMouseHandler
|
|
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 TQWSCalibratedMouseHandler.
|
|
<p> Subclassing TQWSCalibratedMouseHandler is preferred for touch-panels without
|
|
kernel filtering; inheriting TQWSMouseHandler is the way to add any other
|
|
type of pointing device (pen tablets, touchscreens, mice, trackballs
|
|
and so forth).
|
|
<p> <h2> TQWSDisplay
|
|
</h2>
|
|
<a name="16"></a><p> This class exists only in the TQt/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 TQt/Embedded window behaviour (alpha blended windows
|
|
for example).
|
|
<p> <h2> <a href="qwsserver.html">TQWSServer</a>
|
|
</h2>
|
|
<a name="17"></a><p> This manages the TQt/Embedded server's Unix-domain socket connections to
|
|
clients. It sends and receives TQWS protocol events and calls TQWSDisplay
|
|
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 TQt/Embedded
|
|
applications (in which case modify TQWSClient too). If you have
|
|
something like Unix domain sockets, modify TQWSSocket/TQWSServerSocket
|
|
instead. Don't add extra TQWS events to communicate between
|
|
applications, use TQCOP instead.
|
|
<p> <h2> TQWSClient
|
|
</h2>
|
|
<a name="18"></a><p> This encapsulates the client side of a TQt/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
|
|
TQt/Embedded applications.
|
|
<p> <h2> TQWSDisplayData
|
|
</h2>
|
|
<a name="19"></a><p> This manages a client's TQWSClient, reading and interpreting events
|
|
from the TQWS server. It connects to the TQWS 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 TQLinuxFbScreen.
|
|
<p> There should be no reason to modify this.
|
|
<p> <h2> TQWSCommands
|
|
</h2>
|
|
<a name="20"></a><p> These encapsulate the data sent to and from the TQWS server.
|
|
<p> There should be no reason to modify them.
|
|
<p> <h2> <a href="qcopchannel.html">TQCopChannel</a>
|
|
</h2>
|
|
<a name="21"></a><p> TQCop is a simple IPC mechanism for communication between TQt/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> TQWSManager
|
|
</h2>
|
|
<a name="22"></a><p> This provides TQt/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">TQWSDecoration</a>
|
|
</h2>
|
|
<a name="23"></a><p> Descendants of this class are different styles for the TQt/Embedded
|
|
window manager, for instance TQWSWindowsDecoration draws TQt/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> TQWSPropertyManager
|
|
</h2>
|
|
<a name="24"></a><p> This provides the TQWS client's interface to the TQWS 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> TQWSRegionManager
|
|
</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> TQWSSocket, TQWSServerSocket
|
|
</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 © 2007
|
|
<a href="troll.html">Trolltech</a><td align=center><a href="trademarks.html">Trademarks</a>
|
|
<td align=right><div align=right>TQt 3.3.8</div>
|
|
</table></div></address></body>
|
|
</html>
|