1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
|
<!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>$QTDIR/etc/fonts/fontdir</tt> (or <tt>/usr/local/etc/qt-embedded/fonts/fontdir</tt> if QTDIR 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>
|
