these are the different widgets for the screens. they can also be embedded
in the screens itself.
+pixmap paths
+============
+there is no lookup order, but exactly one place to search for pixmaps.
+You can either:
+ - specify a full pathname (PLEASE, don't!), with a leading slash.
+ - specify a relative pathname, without leading slash.
+ The file will be searched for under the default skin image directory.
+ use this to refer to pixmaps which are included in the default
+ distribution, i.e. no skin specific stuff but for example the
+ number bitmaps etc.
+ - relative to the skin's directory (with a leading "~/").
+ ~ in this case can be seen as the skin's "home directory", that's the
+ place where the skin.xml is.
+ use this if you are building a skin.
A NOTE ABOUT PNGs
=================
(*) Note, that, technically, if we start with a alpha=1 background (i.e.
only video), and alphablend on this, we generalized the problem enough that
we can handle both cases the same. But currently, we have to differentiate
-between them, as we can't always alphablend.
+between them, as we can't always alphablend simply for performance reasons.
+
+lcd:
+====
+
+Right now, most lcd-skins ("summary screens") are implemented right in the
+python screens. However, you can override them with regular skinfiles.
+
+There is some confusion about the actual size of the LCD. For now, assume it
+to be 132x64 pixel, but think of the fact that some (most?) hardware can
+only display either 128 (dreambox) or 120 (dbox2, dm8000) pixels
+horizontally.
+
+Right now some pixels will be cropped, currently at the right side. This
+will be (hopefully) fixed soon, so that the used pixels are always in the
+center.
+
+So, bottom line:
+
+Design LCD skins for 132x64, with no important items (text etc.) at the
+outermost 6 pixels on each side. In doubt, leave them white.
+
+LCD colorspace:
+===============
+
+current LCDs are not able to display grayscale graphics. For this, there
+will be a 1bit quantization. However, skins should be designed for 8bit
+grayscale (and still look good in 1bit!), because some next-generation
+display might be able to display some shades of gray - likely not 256, but
+maybe 16 or so.