[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6.6.1 Concepts

There is nothing new in CSWS regarding the window system. All base conceptions for building such an system were invented long ago, at least when first X-Windows system was built, or even earlier.

The system is event-based, events are generated by hardware (mouse, keyboard) or software (components can send messages to each other). Event-system is system-dependent as well as graphics subsystem. They were developed first as part of Crystal Space itself, then some modifications were made to better fit CSWS requirements. CSWS itself is completely system-independent, i.e. you can easily develop programs that will compile and work with no problems under any system supported by Crystal Space.

Since Crystal Space always uses buffered visuals, the screen repainting is always done on the invisible page. This means flickering on redraw is almost impossible in CSWS, while it is common on many GUIs with poorly-written programs. If visual has more than one back-buffer, the image is automatically re-synchronized on all back-buffers, but this slows down the refresh. Thus if your program is mostly using the windowing system it is advised that you disable double-buffering before using the windowing system.

Another Crystal Space-specific feature is the division of event processing into frames. Since Crystal Space is a animation engine it operates in terms of frames, thus when the frame begins, all pending events in event queue are processed, then all invalid components are redrawn, and at last the image is blitted onto the screen. Note that CSWS shares the global event queue used by all plug-ins (and strictly speaking CSWS behaves like a plug-in from system driver's point of view). This means other plug-ins can "steal" events from the windowing system (if they improperly designed).

Basic Concepts

This section provides an overview of the basic concepts of coordinate system and color palette. These discussions provide a solid foundation for subsequent discussions.

Coordinate System

The coordinate system is based on most-used (yet undesirable) system where top-left corner is (0,0) and bottom-right corner is (width, height). It would be better to use the more desirable coordinate system which is used, but most programmers are already familiar with the less desirable one.

Most CSWS functions works with rectangles (`csRect' class). The `csRect' class has four data fields: `xmin', `xmax', `ymin', and `ymax', which are self-explanatory. Here is a example of the rectangle (xmin = 0, ymin = 0, xmax = 3, ymax = 2):

 
     0  1  2  3  4 ...
     |  |  |  |  |  |
 0 --##########--+--+--
     #//|//|//#  |  |
 1 --#--+--+--#--+--+--
     #//|//|//#  |  |
 2 --##########--+--+--
     |  |  |  |  |  |
 3 --+--+--+--+--+--+--
     |  |  |  |  |  |
...--+--+--+--+--+--+--

Vertical line `X = 3' and horizontal line `Y = 2' do not belong to the rectangle. The hashed pixels belong to the rectangle. So, if you have two windows: (0, 0) - (3, 2) and (3, 0) - (6, 2) they do not overlap.

Palette

CSWS has been designed to operate transparently and independent of screen geometry or number of colors. To allow normal operation in different pixel format conditions colors are kept in a dynamically-built table which is referenced through indexes in that table. To allow different palettes for windowing system each component does not use colors directly when drawing, instead each component has a pointer to a table which contains color values. So, for example, a component can have a palette which's first element is used as background color, second is used to display text in window and so on. By changing only the palette table we can change at once how all these components are looking.

There are a number of pre-defined colors with names of the form `cs_Color_XXX', for example `cs_Color_Black', `cs_Color_White' etc. There are some colors with varying intensities which are named `cs_Color_YYY_Z'; where YYY is something like `Blue', `Red', and so on; and the Z suffix stands for the intensity---`D' for dark, `M' for medium, `L' for light.

There are a small number of pre-defined colors. What if you want to use a color that is not predefined as a screen-depth-independent constant? The answer is, you can use csApp::FindColor() to find a integer representation of the color (which is very hardware dependent) given the <r,g,b> components of the color (where r, g, and b are in the range 0-255). Then you use the returned color identifier in the same places where a `cs_Color_XXX' value is expected.

Note that the FindColor() method never fails: it always returns the nearest available color. But keep in mind that if you have a palette full of just black and white colors and you ask for bright red, you will most likely get some sort of white (or gray) color, rather than red. Palette management is outside of the scope of this document; see the Texture Manager documentation instead.

To avoid hard-coding colors into the windowing system components do not draw with `cs_Color_XXX' constants. Instead, they just indicate the index into the palette representing the color they wish to use. All standard component palettes are contained in `cswspal.cpp' and `cswspal.h'.

There is no need to add your palettes to `cswspal.cpp'; that file is just a convenience for standard windowing system components. Your components should define their own palettes (if desired) and set the palette at startup (in the constructor) using the SetPalette() method. Then you draw using palette indices, just like standard CSWS components. It is strongly advised to not use numerical indices for this, but instead define a set of macros of the form `XXPAL_YYYY_BACKGROUND', `XXPAL_ZZZZ_ACTIVETEXT' and so on; where XX is the short name of your application (`CS' for `C'rystal `S'pace, `MZ' for MazeD, the Maze Editor, and so on); YYYY and ZZZZ are the names of the respective components, and the suffix gives the meaning of that palette entry.

For illustration here are the palette indices for the standard CSWS scroll bar palette:

 
#define CSPAL_SCROLLBAR_BACKGROUND      0
#define CSPAL_SCROLLBAR_SELBACKGROUND   1
#define CSPAL_SCROLLBAR_DARK3D          2
#define CSPAL_SCROLLBAR_LIGHT3D         3

If you want to change a specific palette entry for a specific component, you can use the SetColor() method. You should provide a index into the target component's palette and a color (one of `cs_Color_XXX' constants defined above). For example, to set the background color for some scrollbar to bright red, you can use the call:

 
csScrollBar* sb; // Assume that this points at a scroll bar.
sb->SetColor(CSPAL_SCROLLBAR_BACKGROUND, cs_Color_Red_L);


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

This document was generated using texi2html