diff options
| author | Timothy Pearson <[email protected]> | 2011-11-08 12:31:36 -0600 |
|---|---|---|
| committer | Timothy Pearson <[email protected]> | 2011-11-08 12:31:36 -0600 |
| commit | d796c9dd933ab96ec83b9a634feedd5d32e1ba3f (patch) | |
| tree | 6e3dcca4f77e20ec8966c666aac7c35bd4704053 /doc/html/emb-classes.html | |
| download | tqt3-d796c9dd933ab96ec83b9a634feedd5d32e1ba3f.tar.gz tqt3-d796c9dd933ab96ec83b9a634feedd5d32e1ba3f.zip | |
Test conversion to TQt3 from Qt3 8c6fc1f8e35fd264dd01c582ca5e7549b32ab731
Diffstat (limited to 'doc/html/emb-classes.html')
| -rw-r--r-- | doc/html/emb-classes.html | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/html/emb-classes.html b/doc/html/emb-classes.html new file mode 100644 index 000000000..0b9001bf3 --- /dev/null +++ b/doc/html/emb-classes.html @@ -0,0 +1,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 retquire 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="qpainter.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> |