Wiley.Symbian.OS.C.plus.plus.for.Mobile.Phones.Aug.2007 (Symbian Books), страница 100

Initialization of a TRgb from one of these‘constants’ is no more expensive than if we used const TRgb. AllCGraphicsContext color specifications for pens and brushes useTRgb values. The graphics device then converts these into devicedependent color values internally.2These colors are named after the Enhanced Graphics Adapter of the IBM PC, whichsupported them and introduced them into character set attributes.DEVICE- AND SIZE-INDEPENDENT GRAPHICS553With measurements and fonts, you have to convert to device-dependent units (pixels and CFonts) before calling CGraphicsContextfunctions. The same approach could have been taken with colors but itwasn’t, because the meaning of a color is less device-dependent than thesize of a pixel or the bitmap for a font.Concrete color values such as KRgbBlack are useful in manysituations.

There are also some logical color values, defined in TLogicalColor, which refer to colors used in the user interface scheme,such as the colors used in menus, menu highlights, toolbar buttons orwindow shadows. The choice of which physical colors these logicalvalues correspond to belongs to the device OEM. The mapping is storedin a CColorList object, which supports:• logical-to-RGB color mappings loaded from resource files or specifiedprogrammatically• independent sections for the system and applications: a section isidentified by a UID and a logical color by an enumerated constant• mappings for four-grayscale and 256-color schemes: the 256-colorscheme is used and looks good if the screen mode supports 16 ormore colors; otherwise, the four-grayscale scheme is used.An application can access the color list through CEikonEnv::ColorList().A key thing you have to know about a device is how many colorsit supports.

Actually, the number of supported colors depends not onlyon the device, but also on the current display mode of the device. Mostdevices have a preferred display mode, and some support multiple displaymodes: you can check the display modes supported by a window-serverscreen device and set your window to use a required display mode if itis supported. Some display modes consume more power than others, sothe window server changes the display mode in use to the one with theminimum power requirement for any visible window.You can create bitmaps in any display mode.

When you blit them ontoanother bitmap or a display them in a particular mode, the bitmap datais contracted or expanded as necessary to match the display mode of thetarget bitmap. The display modes supported by Symbian OS are definedin the TDisplayMode enumeration in gdi.h (see Table 17.3).The window server sets the screen’s display mode to the least capablemode required by any currently visible window and supported by thehardware. So the ‘preferred screen display mode’ is actually implementedas a ‘default window display mode’. There may be a trade-off herebetween higher display modes and lower power consumption. ROMbitmaps should be generated in the preferred display mode, so that nobitmap transformations are required when blitting to the screen.554GRAPHICS FOR DISPLAYTable 17.3 TDisplayMode EnumerationModeBitsTypeCommentA null value that shouldn’t bepresent in any initializedTDisplayMode objectENoneEGray21GrayscaleKRgbBlack and KRgbWhite;mainly used for bitmap masksEGray42GrayscaleOnly KRgbBlack,KRgbDarkGray, KRgbGray andKRgbWhite; the default displaymode on the Psion Series 5EGray164Grayscale16 shades of gray; the alternate,higher-definition, display modeon the Psion Series 5EGray2568Grayscale256 shades of gray; mainly usedfor alpha-channel bitmaps forblendingEColor164ColorFull EGA color set: all standardKRgb values; never used as adisplay mode on a real deviceEColor2568ColorThe Netscape color cube:represents all 216 combinationsof R, G and B in multiples of0x33, plus all remaining 40combinations of pure R, pure G,pure B and pure gray in multiplesof 0x11; never used as a displaymode on a real deviceEColor64K16ColorHigh color: represents 5 bits of R,6 bits of G and 5 bits of B, so that0xrrrrrrrr, 0xgggggggg,0xbbbbbbbb converts toTRgb(0xrrrrr000,0xgggggg00, 0xbbbbb000),with the least significant bits ofeach color being dropped;commonly used on older devicesEColor16M24ColorRepresents 8 bits each for R, Gand B; never used in practisebecause it is very inefficientERgb32ColorA buffer of TRgb objects; notactually a valid displaymode – only used for exportingdataDEVICE- AND SIZE-INDEPENDENT GRAPHICS555Table 17.3 (continued )ModeBitsTypeCommentEColor4K16ColorRepresents 4 bits each for R, Gand B; 4 bits are wastedEColor16MU32ColorRepresents 8 bits each for R, Gand B; 8 bits wasted; the mostcommon display mode in usetodayEColor16MA32ColorRepresents 8 bits each for R, Gand B and 8 bits alpha; thesemi-transparent display modeIf a color is passed to a CGraphicsContext function that is notsupported exactly on the device, then the nearest supported color isused instead.

We are quite used to having real-world colors mappeddown onto black-and-white or low-fidelity color. The best approach forreal-world colors is to allow the TDisplayMode mappings to do theirthing.Finally, you may want the user to select a color, for example in adrawing program. Some GUIs supply a control for this: in UIQ, it isCQikColorSelector.This nearest-color transformation is done before any other operationuses the color, including logical operations such as XOR.

This canproduce unexpected effects, but logical operations are in any case ofdubious value on windowing systems – with the exception of XORingwith KRgbWhite, which has its uses and always works as expected.Some GDI definitions mention ‘palettes’; these were added to thedesign before support for any form of color display was implemented(in Symbian OS v5). When support for a color display mode was added,palettes were not used to optimize the shades available in a 256-colordisplay mode. The fixed Netscape color cube set was used instead.This reduced the complexity of the API, while losing no worthwhilefeatures for devices in this class and avoiding the oddities that wereoccasionally seen on Windows PCs when the palette was optimizedfor a foreground window. This proved to be a sensible decision as the256-color display mode was never used in a real device.Web browsingWeb-browsing technology is often confused on the subjects of target andsize-independence. It has evolved without clear distinctions between printand on-screen graphics and without a consistent way of re-sizing.

Text is556GRAPHICS FOR DISPLAYspecified in HTML – which is device-independent – while pictures (Gifs,Jpegs or BMPs) are specified in pixels. The physical size of the graphicsthen vary depending on the resolution of the screen – they are smalleron higher resolution screens.

There is no clear relationship between textsizes and graphics, which means they do not scale together on mostbrowsers. However, there are ways around these problems and text andpictures scale together on Symbian OS browsers.SummaryIn this chapter, we have concentrated on graphics for display – how todraw and how to share the screen.

More specifically, we have seen:• the CGraphicsContext class and its API for drawing, getting position and bounding rectangles• the MVC pattern, which is the natural paradigm for most SymbianOS applications; MVC updates and redraws work well with standardRWindow objects; for non-MVC programs, or programs whose updatesare particularly complex, backed-up windows may be more usefulinstead• how the work is shared between controls and windows• the use of compound controls to simplify layout• the difference between window-owning and lodger controls• application- and system-initiated drawing• techniques for flicker-free drawing and how CONE helps you achievethis• the use of ActivateGC() and BeginRedraw() in functions suchas DrawNow().• the CCoeControl functions for drawing• how to animate, scroll and use back-up-behind and transparent windows• use of the window server’s drawing features: flicker-free redrawingand redraw storing• drawing in device-independent ways: fonts, zooming views, printing,bitmaps and color.18Graphics for InteractionIn Chapter 17, we saw the way that Symbian OS uses the MVC pattern,and how to draw in the context of controls and windows.

In this chapter,we cover how to use controls to enable user interaction with yourprograms.In theory, it is easy. Just as controls provide a virtual Draw() function for drawing, they also provide two virtual functions for handlinginteraction: HandlePointerEventL() for pointer events and OfferKeyEventL() for key events.

You simply work out the coordinatesof the pointer event, or the key code for the key event, and decidewhat to do.Basic interaction handling does indeed involve knowing how to usethese two functions and we start the chapter by describing them. We alsoshow that interaction is well suited to MVC: you turn key and pointerevents into commands to update the model and then let the model handleredrawing. However, this description of key- and pointer-event handlingis really just the tip of the interaction iceberg. There are plenty of otherissues to deal with:• key events are normally associated with a cursor location or the moregeneral concept of focus – but not all key events go to the currentfocus location and some key events cause focus to be changed• a ‘pointer down’ event away from the current focus usually causesfocus to be changed; sometimes, though, it is not good to changefocus – perhaps because the currently focused control is not in a validstate or because the control where the event occurred doesn’t acceptfocus• focus should be indicated by some visual effect (usually a cursoror a highlight); likewise, temporary inability to take focus should be558GRAPHICS FOR INTERACTIONindicated by a visual effect (usually some kind of dimming or makinga control invisible)• the rules governing focus and focus transition should be easy toexplain to users – better still, they shouldn’t need to be explained atall; they should also be easy to explain to programmers.The big issues in interaction are intimately related: drawing, pointerhandling, key handling, model updates, component controls, focus, validity, temporary unavailability, ease of use and ease of programming.