source: trunk/doc/html/emb-classes.html@ 190

Last change on this file since 190 was 190, checked in by rudi, 14 years ago

reference documentation added
File size: 16.8 KB
Line 
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
2<!-- /home/espenr/tmp/qt-3.3.8-espenr-2499/qt-x11-free-3.3.8/doc/embclasses.doc:36 -->
3<html>
4<head>
5<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
6<title>The Qt/Embedded-specific classes</title>
7<style type="text/css"><!--
8fn { margin-left: 1cm; text-indent: -1cm; }
9a:link { color: #004faf; text-decoration: none }
10a:visited { color: #672967; text-decoration: none }
11body { background: #ffffff; color: black; }
12--></style>
13</head>
14<body>
15
16<table border="0" cellpadding="0" cellspacing="0" width="100%">
17<tr bgcolor="#E5E5E5">
18<td valign=center>
19 <a href="index.html">
20<font color="#004faf">Home</font></a>
21 | <a href="classes.html">
22<font color="#004faf">All&nbsp;Classes</font></a>
23 | <a href="mainclasses.html">
24<font color="#004faf">Main&nbsp;Classes</font></a>
25 | <a href="annotated.html">
26<font color="#004faf">Annotated</font></a>
27 | <a href="groups.html">
28<font color="#004faf">Grouped&nbsp;Classes</font></a>
29 | <a href="functions.html">
30<font color="#004faf">Functions</font></a>
31</td>
32<td align="right" valign="center"><img src="logo32.png" align="right" width="64" height="32" border="0"></td></tr></table><h1 align=center>The Qt/Embedded-specific classes</h1>
33
34
35
36<p> Qt/Embedded classes fall into two groups: the majority are used by
37every Qt/Embedded program, and some are used only by the Qt/Embedded server.
38The Qt/Embedded server program can also be a client, as in the case of a
39single-process installation. All Qt/Embedded specific source files live
40in <tt>src/kernel</tt> and are suffixed <tt>_qws</tt>. The &raquo; symbol
41indicates inheritance.
42<p> <!-- toc -->
43<ul>
44<li><a href="#1"> QFontManager
45</a>
46<li><a href="#2"> QDiskFont
47</a>
48<li><a href="#3"> QRenderedFont
49</a>
50<li><a href="#4"> QFontFactory (and descendants QFontFactoryBDF, QFontFactoryTtf)
51</a>
52<li><a href="#5"> QGlyph
53</a>
54<li><a href="#6"> QMemoryManagerPixmap/QMemoryManager
55</a>
56<li><a href="#7"> QScreen &raquo; QLinuxFbScreen &raquo; accelerated screens, QTransformedScreen &raquo; QVfbScreen
57</a>
58<li><a href="#8"> QScreenCursor &raquo; accelerated cursor &raquo; QVfbCursor
59</a>
60<li><a href="#9"> QGfx &raquo; RasterBase &raquo; Raster &raquo; accelerated driver &raquo; QGfxVfb &raquo; QGfxTransformedRaster
61</a>
62<li><a href="#10"> QLock, QLockHolder
63</a>
64<li><a href="#11"> QDirectPainter
65</a>
66<li><a href="#12"> QWSSoundServer, Client
67</a>
68<li><a href="#13"> QWSWindow
69</a>
70<li><a href="#14"> QWSKeyboardHandler &raquo; subtypes
71</a>
72<li><a href="#15"> QWSMouseHandler &raquo; QWSCalibratedMouseHandler &raquo; mouse types
73</a>
74<li><a href="#16"> QWSDisplay
75</a>
76<li><a href="#17"> QWSServer
77</a>
78<li><a href="#18"> QWSClient
79</a>
80<li><a href="#19"> QWSDisplayData
81</a>
82<li><a href="#20"> QWSCommands
83</a>
84<li><a href="#21"> QCopChannel
85</a>
86<li><a href="#22"> QWSManager
87</a>
88<li><a href="#23"> QWSDecoration
89</a>
90<li><a href="#24"> QWSPropertyManager
91</a>
92<li><a href="#25"> QWSRegionManager
93</a>
94<li><a href="#26"> QWSSocket, QWSServerSocket
95</a>
96</ul>
97<!-- endtoc -->
98
99<p> <h2> <a href="qfontmanager.html">QFontManager</a>
100</h2>
101<a name="1"></a><p> There is one of these per application. At application startup time it
102reads 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
103keeps track of all font information and maintains a cache of rendered
104fonts. It also creates the font factories: QFontManager::QFontManager
105is the place to add constructors for new factories. It provides a
106high-level interface for requesting a particular font and calls
107QFontFactories to load fonts from disk on demand. Note that this only
108applies to BDF and TrueType fonts; Qt/Embedded's optimised <tt>.qpf</tt>
109font file format bypasses the QFontManager mechanism altogether.
110<p> There should be no need to modify this class unless you wish to change
111font matching or caching behaviour.
112<p> <h2> QDiskFont
113</h2>
114<a name="2"></a><p> This contains information about a single on-disk font file (e.g.
115<tt>/usr/local/etc/qt-embedded/times.ttf</tt>). It holds the file path,
116information about whether the font is scalable, its weight, size,
117Qt/Embedded name, etc. This information is used so that <a href="qfontmanager.html">QFontManager</a>
118can find the closest matching disk font (it uses a scoring mechanism
119weighted towards matching names, then whether the font's italic, then
120its weight).
121<p> There should be no reason to modify this class.
122<p> <h2> QRenderedFont
123</h2>
124<a name="3"></a><p> There is one and only one QRenderedFont for every unique font
125currently loaded by the system (that is, each unique combination of
126name, size, weight, italic or not, anti-aliased or not).
127QRenderedFonts are reference counted; once no one is using the
128QRenderedFont it is deleted along with its cache of glyph bitmaps. The
129QDiskFont it was loaded from remains opened by its QFontFactory.
130<p> There should be no reason to modify this class, unless you wish to
131change the way in which glyphs are cached.
132<p> <h2> QFontFactory (and descendants QFontFactoryBDF, QFontFactoryTtf)
133</h2>
134<a name="4"></a><p> These provide support for particular font formats, for instance the
135scalable Truetype and Type1 formats (both supported in
136QFontFactoryTtf, which uses Freetype 2) and the bitmap BDF format used
137by X. It's called to open an on-disk font; once a font is opened it
138remains opened so that the creation of new font instances from the
139disk font is fast. It can also create a QRenderedFont and convert from
140Unicode values to an index into the font file. For compactness, glyphs
141are stored in the order and indexes they are defined in the font
142rather than in Unicode order.
143<p> There should be no need to modify this class, but it should be
144inherited if you wish to add a different type of font renderer (e.g.
145for a custom vector font format).
146<p> <h2> QGlyph
147</h2>
148<a name="5"></a><p> This describes a particular image of a character from a QRenderedFont:
149for example, the letter 'A' at 10 points in Times New Roman, bold italic,
150anti-aliased. It contains pointers to a QGlyphMetrics structure with
151information about the character and to the raw data for the glyph:
152this is either a 1-bit mask or an 8-bit alpha channel. Each QRenderedFont
153creates these on demand and caches them once created (note that this is
154not currently implemented for TrueType fonts).
155<p> You would only need to modify this class if you were, for example,
156modifying Qt/Embedded to support textured fonts, in which case you
157would also need to modify QGfxRaster.
158<p> <h2> QMemoryManagerPixmap/QMemoryManager
159</h2>
160<a name="6"></a><p> This handles requests for space for pixmaps and also keeps track of
161QPF format fonts (these are small 'state dumps' of QRenderedFonts,
162typically 2-20KB in size; they can be mmap'd direct from disk in order
163to save memory). If a QPF font is found which matches a font request
164no new QRenderedFont need be created for it. It's possible to strip out
165all QFontFactory support and simply use QPFs if your font needs are modest
166(for instance, if you only require a few fixed point sizes). Note that
167no best-match loading is performed with QPFs, as opposed to those
168loaded via <a href="qfontmanager.html">QFontManager</a>, so if you don't have the correct QPF for a point
169size, text in that size will simply not be displayed.
170<p> There should be no need to modify this class.
171<p> <h2> <a href="qscreen.html">QScreen</a> &raquo; QLinuxFbScreen &raquo; accelerated screens, QTransformedScreen &raquo; QVfbScreen
172</h2>
173<a name="7"></a><p> These encapsulate the framebuffer Qt/Embedded is drawing to, provide
174support for mapping of coordinates for rotating framebuffers, allow
175manipulation of the colour palette and provide access to offscreen
176graphics memory for devices with separate framebuffer memories.
177<p> This is used for caching pixmaps and allowing accelerated pixmap=&gt;screen
178blt's. QLinuxFbScreen and the accelerated screens use the Linux <tt>/dev/fb</tt>
179interface to get access to graphics memory and information about the
180characteristics of the device. The framebuffer device to open is specified
181by QWS_DISPLAY. Only QTransformedScreen implements the support for rotated
182framebuffers. QVfbScreen provides an X window containing an emulated
183framebuffer (a chunk of shared memory is set aside as the 'framebuffer'
184and blt'd into the X window): this is intended as a debugging device
185allowing users to debug their applications under Qt/Embedded without leaving
186X. The accelerated screen drivers check to see if they can drive the
187device specified by QWS_CARD_SLOT (which defaults to the usual position
188of an AGP slot if not specified) and mmap its on-chip registers from
189<tt>/dev/mem</tt>. They may also do chip-specific setup (initialising registers to
190known values and so on). Finally, <a href="qscreen.html">QScreen</a>'s are used to create new
191QScreenCursors and QGfxes.
192<p> If you wish to modify the way pixmaps are allocated in memory,
193subclass or modify QLinuxFbScreen. If you're writing an accelerated
194driver you will need to subclass QScreen or QLinuxFbScreen.
195<p> <h2> QScreenCursor &raquo; accelerated cursor &raquo; QVfbCursor
196</h2>
197<a name="8"></a><p> This handles drawing the on-screen mouse cursor, and saving and
198restoring the screen under it for the non-accelerated cursor types.
199<p> Subclassing QScreenCursor is optional in an accelerated driver (you
200would only want to do so if the hardware supports a hardware cursor).
201<p> <h2> QGfx &raquo; RasterBase &raquo; Raster &raquo; accelerated driver &raquo; QGfxVfb &raquo; QGfxTransformedRaster
202</h2>
203<a name="9"></a><p> This class encapsulates drawing operations, a little like a low-level
204<a href="qpainter.html">QPainter</a>. QGfxRaster and its descendants are specifically intended
205for drawing into a raw framebuffer. They can take an offset for drawing
206operations and a clipping region in order to support drawing into windows.
207You will need to subclass the QGfxRaster template in order to implement
208an accelerated driver.
209<p> If you're brave, modifying QGfxRaster would allow you to customise how
210drawing is done or add support for a new bit depth/pixel format.
211<p> <h2> QLock, QLockHolder
212</h2>
213<a name="10"></a><p> This encapsulates a System V semaphore, used for synchronising access
214to memory shared between Qt/Embedded clients. QLockHolder is a utility class
215to make managing and destroying QLocks easier.
216<p> There should be no need to modify this class unless porting
217Qt/Embedded to an operating system without System V IPC.
218<p> <h2> <a href="qdirectpainter.html">QDirectPainter</a>
219</h2>
220<a name="11"></a><p> This is a QPainter which also gives you a pointer to the framebuffer
221of the window it's pointing to, the window's clip region and so on.
222It's intended to easily allow you to do your own pixel-level manipulation
223of window contents.
224<p> There should be no reason to modify this class.
225<p> <h2> QWSSoundServer, Client
226</h2>
227<a name="12"></a><p> The Qt/Embedded server contains a simple sound player and mixer. Clients
228can request the server play sounds specified as files.
229<p> There should be no need to modify this class unless porting
230Qt/Embedded to an operating system without a Linux-style <tt>/dev/dsp</tt>.
231<p> <h2> <a href="qwswindow.html">QWSWindow</a>
232</h2>
233<a name="13"></a><p> This contains the server's notion of an individual top level window:
234the region of the framebuffer it's allocated, the client that created it
235and so forth.
236<p> There should be no reason to modify this class.
237<p> <h2> <a href="qwskeyboardhandler.html">QWSKeyboardHandler</a> &raquo; subtypes
238</h2>
239<a name="14"></a><p> This handles keyboard/button input. QWSKeyboardHandler is subclassed
240to provide for reading <tt>/dev/tty</tt>, an arbitrary low-level USB event device
241(for USB keyboards) and some PDA button devices.
242<p> Modifying QWSKeyboardHandler would allow you to support different
243types of keyboard (currently only a fairly standard US PC style
244keyboard is supported); subclassing it is the preferred way to handle
245non-pointer input devices.
246<p> <h2> <a href="qwsmousehandler.html">QWSMouseHandler</a> &raquo; QWSCalibratedMouseHandler &raquo; mouse types
247</h2>
248<a name="15"></a><p> This handles mouse/touch-panel input. Descendants of QWSCalibratedMouseHandler
249make use of filtering code which prevents 'jittering' of the pointer on
250touchscreens; some embedded devices do this filtering in the kernel in
251which case the driver doesn't need to inherit from QWSCalibratedMouseHandler.
252<p> Subclassing QWSCalibratedMouseHandler is preferred for touch-panels without
253kernel filtering; inheriting QWSMouseHandler is the way to add any other
254type of pointing device (pen tablets, touchscreens, mice, trackballs
255and so forth).
256<p> <h2> QWSDisplay
257</h2>
258<a name="16"></a><p> This class exists only in the Qt/Embedded server and keeps track of
259all the top-level windows in the system, as well as the keyboard and mouse.
260<p> You would only want to modify this if making deep and drastic
261modifications to Qt/Embedded window behaviour (alpha blended windows
262for example).
263<p> <h2> <a href="qwsserver.html">QWSServer</a>
264</h2>
265<a name="17"></a><p> This manages the Qt/Embedded server's Unix-domain socket connections to
266clients. It sends and receives QWS protocol events and calls QWSDisplay
267in order to do such things as change the allocation region of windows.
268<p> The only reason to modify this would be to use something other than
269some sort of socket-like mechanism to communicate between Qt/Embedded
270applications (in which case modify QWSClient too). If you have
271something like Unix domain sockets, modify QWSSocket/QWSServerSocket
272instead. Don't add extra QWS events to communicate between
273applications, use QCOP instead.
274<p> <h2> QWSClient
275</h2>
276<a name="18"></a><p> This encapsulates the client side of a Qt/Embedded connection and can
277marshal and demarshal events.
278<p> There should be no reason to modify this except to use something
279radically different from Unix domain sockets to communicate between
280Qt/Embedded applications.
281<p> <h2> QWSDisplayData
282</h2>
283<a name="19"></a><p> This manages a client's QWSClient, reading and interpreting events
284from the QWS server. It connects to the QWS server on application
285startup, getting information about the framebuffer and creating the
286memory manager. Other information about the framebuffer comes directly
287from <tt>/dev/fb</tt> in QLinuxFbScreen.
288<p> There should be no reason to modify this.
289<p> <h2> QWSCommands
290</h2>
291<a name="20"></a><p> These encapsulate the data sent to and from the QWS server.
292<p> There should be no reason to modify them.
293<p> <h2> <a href="qcopchannel.html">QCopChannel</a>
294</h2>
295<a name="21"></a><p> QCop is a simple IPC mechanism for communication between Qt/Embedded
296applications. String messages with optional binary data can be sent
297to different channels.
298<p> The mechanism itself is designed to be bare-bones in order for users
299to build whatever mechanism they like on top of it.
300<p> <h2> QWSManager
301</h2>
302<a name="22"></a><p> This provides Qt/Embedded window management, drawing a title bar
303and handling user requests to move, resize the window and so on.
304<p> There should be no reason to modify it but you should subclass it
305if you want to modify window behaviour (point to click versus
306focus follows mouse, for instance).
307<p> <h2> <a href="qwsdecoration.html">QWSDecoration</a>
308</h2>
309<a name="23"></a><p> Descendants of this class are different styles for the Qt/Embedded
310window manager, for instance QWSWindowsDecoration draws Qt/Embedded
311window frames in the style of Windows CE.
312<p> Subclass it in order to provide a new window manager appearance (the
313equivalent of a Windows XP or Enlightenment theme).
314<p> <h2> QWSPropertyManager
315</h2>
316<a name="24"></a><p> This provides the QWS client's interface to the QWS property system
317(a simpler version of the X property system, it allows you to attach
318arbitrary data to top-level windows, keyed by an integer).
319<p> There should be no reason to modify it.
320<p> <h2> QWSRegionManager
321</h2>
322<a name="25"></a><p> Used by both client and server to help manage top-level window regions.
323<p> There should be no reason to modify it.
324<p> <h2> QWSSocket, QWSServerSocket
325</h2>
326<a name="26"></a><p> Provides Unix-domain sockets.
327<p> Modify this if you're porting to a non-Unix OS but have something
328analogous to Unix-domain sockets (a byte-oriented, reliable, ordered
329transmission mechanism, although you can probably implement it with
330something like a message queue as well).
331<p>
332<!-- eof -->
333<p><address><hr><div align=center>
334<table width=100% cellspacing=0 border=0><tr>
335<td>Copyright &copy; 2007
336<a href="troll.html">Trolltech</a><td align=center><a href="trademarks.html">Trademarks</a>
337<td align=right><div align=right>Qt 3.3.8</div>
338</table></div></address></body>
339</html>
Note: See TracBrowser for help on using the repository browser.