Chapter 1

world colors mapped down onto black and white or low-fidelity color. The best approach for
real-world colors is simply to allow the TDisplayMode mappings to do their thing.
Note
This nearest-color transformation is done before any other operation uses
the color, including logical operations such as XOR. This can produce
unexpected effects, but logical operations are in any case of dubious value
on windowing systems – with the exception of XORing with KRgbWhite,
which has its uses and will always work as expected.
You'll see mentions of 'palettes' in some of the GDI definitions; these were
added to the design before support for any form of color display was
implemented (in Symbian OS v5). When color display mode support was
added, not to use palettes to optimize (say) the shades available in a 256color
display mode. Instead, we use the fixed Netscape color cube set, and
that's it. This reduces the complexity of the API, loses no worthwhile features
for devices in this class, and avoids the funnies you occasionally see (or
remember seeing!) on Windows PCs when the palette was optimized for a
foreground window while other visible windows' palettes went wild.
Finally, you want the user to select a color, for example, in a drawing program. Some GUI's
supply controls for this – in UIQ its CQikColorS-elector.
15.2.5 Web Browsing
Web browsing technology is often confused on the subjects of target and size
independence. It has evolved without clear distinctions between print and on-screen
graphics and without a consistent way of resizing. Text is specified in html – which is deviceindependent
– while pictures (gifs, jpgs, or bmps) are specified in pixels. The physical size of
the graphics will then vary depending on the resolution of the monitor/screen – they will be
smaller for higher resolution monitor/screen displays. There is no clear relation between text
sizes and graphics, which means they don't scale together on most browsers. However,
there are ways around these problems and text and pictures scale together on Symbian OS
browsers.
15.3 The Developer's Quest for Device-independent Code
It is not always worthwhile making your code target-independent. So, when should you make
your drawing code device-independent and when don't you need to? There are two extreme
cases in which the answer is quite clear:
� If your code is designed exclusively for a screen-based UI, then it should not be targetindependent
(though you may wish to build in size independence).
� If your code is designed primarily for printing, with a screen-based UI for editing, then it
should be device-independent.
An application toolbar can be highly device-dependent, as can the menu and the dialogs
(though some size independence in the latter case may be useful). On the other hand, a text
view intended for a word processor should be highly device-independent; so too should a
mapping program that might well be printer-oriented.
15.3.1 Real Devices Intrude
This answer is only a starting point, however, and there are many awkward, intermediate
cases. You have to take the realities of the device into account, even when writing the most
device-independent code.