From d796c9dd933ab96ec83b9a634feedd5d32e1ba3f Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Tue, 8 Nov 2011 12:31:36 -0600 Subject: Test conversion to TQt3 from Qt3 8c6fc1f8e35fd264dd01c582ca5e7549b32ab731 --- doc/html/emb-classes.html | 339 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/html/emb-classes.html (limited to 'doc/html/emb-classes.html') 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 @@ + + + + + +The TQt/Embedded-specific classes + + + + + + + +
+ +Home + | +All Classes + | +Main Classes + | +Annotated + | +Grouped Classes + | +Functions +

The TQt/Embedded-specific classes

+ + + +

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 src/kernel and are suffixed _qws. The » symbol +indicates inheritance. +

+

+ + +

TQFontManager +

+

There is one of these per application. At application startup time it +reads the font definition file from $QTDIR/etc/fonts/fontdir (or /usr/local/etc/qt-embedded/fonts/fontdir 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 .qpf +font file format bypasses the TQFontManager mechanism altogether. +

There should be no need to modify this class unless you wish to change +font matching or caching behaviour. +

TQDiskFont +

+

This contains information about a single on-disk font file (e.g. +/usr/local/etc/qt-embedded/times.ttf). 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 TQFontManager +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). +

There should be no reason to modify this class. +

TQRenderedFont +

+

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. +

There should be no reason to modify this class, unless you wish to +change the way in which glyphs are cached. +

TQFontFactory (and descendants TQFontFactoryBDF, TQFontFactoryTtf) +

+

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. +

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). +

TQGlyph +

+

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). +

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. +

TQMemoryManagerPixmap/TQMemoryManager +

+

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 TQFontManager, so if you don't have the correct TQPF for a point +size, text in that size will simply not be displayed. +

There should be no need to modify this class. +

TQScreen » TQLinuxFbScreen » accelerated screens, TQTransformedScreen » TQVfbScreen +

+

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. +

This is used for caching pixmaps and allowing accelerated pixmap=>screen +blt's. TQLinuxFbScreen and the accelerated screens use the Linux /dev/fb +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 +/dev/mem. They may also do chip-specific setup (initialising registers to +known values and so on). Finally, TQScreen's are used to create new +TQScreenCursors and TQGfxes. +

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. +

TQScreenCursor » accelerated cursor » TQVfbCursor +

+

This handles drawing the on-screen mouse cursor, and saving and +restoring the screen under it for the non-accelerated cursor types. +

Subclassing TQScreenCursor is optional in an accelerated driver (you +would only want to do so if the hardware supports a hardware cursor). +

TQGfx » RasterBase » Raster » accelerated driver » TQGfxVfb » TQGfxTransformedRaster +

+

This class encapsulates drawing operations, a little like a low-level +TQPainter. 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. +

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. +

TQLock, TQLockHolder +

+

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. +

There should be no need to modify this class unless porting +TQt/Embedded to an operating system without System V IPC. +

TQDirectPainter +

+

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. +

There should be no reason to modify this class. +

TQWSSoundServer, Client +

+

The TQt/Embedded server contains a simple sound player and mixer. Clients +can request the server play sounds specified as files. +

There should be no need to modify this class unless porting +TQt/Embedded to an operating system without a Linux-style /dev/dsp. +

TQWSWindow +

+

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. +

There should be no reason to modify this class. +

TQWSKeyboardHandler » subtypes +

+

This handles keyboard/button input. TQWSKeyboardHandler is subclassed +to provide for reading /dev/tty, an arbitrary low-level USB event device +(for USB keyboards) and some PDA button devices. +

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. +

TQWSMouseHandler » TQWSCalibratedMouseHandler » mouse types +

+

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. +

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). +

TQWSDisplay +

+

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. +

You would only want to modify this if making deep and drastic +modifications to TQt/Embedded window behaviour (alpha blended windows +for example). +

TQWSServer +

+

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. +

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. +

TQWSClient +

+

This encapsulates the client side of a TQt/Embedded connection and can +marshal and demarshal events. +

There should be no reason to modify this except to use something +radically different from Unix domain sockets to communicate between +TQt/Embedded applications. +

TQWSDisplayData +

+

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 /dev/fb in TQLinuxFbScreen. +

There should be no reason to modify this. +

TQWSCommands +

+

These encapsulate the data sent to and from the TQWS server. +

There should be no reason to modify them. +

TQCopChannel +

+

TQCop is a simple IPC mechanism for communication between TQt/Embedded +applications. String messages with optional binary data can be sent +to different channels. +

The mechanism itself is designed to be bare-bones in order for users +to build whatever mechanism they like on top of it. +

TQWSManager +

+

This provides TQt/Embedded window management, drawing a title bar +and handling user requests to move, resize the window and so on. +

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). +

TQWSDecoration +

+

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. +

Subclass it in order to provide a new window manager appearance (the +equivalent of a Windows XP or Enlightenment theme). +

TQWSPropertyManager +

+

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). +

There should be no reason to modify it. +

TQWSRegionManager +

+

Used by both client and server to help manage top-level window regions. +

There should be no reason to modify it. +

TQWSSocket, TQWSServerSocket +

+

Provides Unix-domain sockets. +

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). +

+ +

+ +
Copyright © 2007 +TrolltechTrademarks +
TQt 3.3.8
+
+ -- cgit v1.2.1