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
=================
16color (4bit) PNG, which is not really what we want. Either add more colors
(evil workaround), fix enigma (good idea!) or patch pngquant to
always create 8bit pngs.
+
+transparency:
+=============
+
+First, do not mix up transparency with alpha. I agree, both terms refer to
+the same thing, but in our case, it's more complicated. As long as we don't
+run on accelerated graphic, we need to differentiate between these two.
+
+Alpha, in our context, is the ratio between the video and the OSD. Alpha = 0
+means that OSD is completely visible, and no video, whereas Alpha = 1 (or
+0xFF, if you express it so) means that there is only video.
+
+Transparency, on the other hand, is OSD-only. When you have a background,
+say a color, and you want to blit a picture on it, you can mix the
+background with the picture. (*) This allows pixmap with a non-rectangular
+shape.
+
+Because of speed reasons, we don't support real alpha blending when not
+running with acceleration. Instead, we use alpha testing. This means that a
+special color is "transparent", whereas all other colors are not. This
+colors *HAS TO BE AT INDEX 0*. As you can't count on automatic palette
+merging (it's disabled when the target is 32bit, so you you're not
+restricted to 8bit in total, only 8bit per pixmap), you have to tell your
+gfx program to put the transparent color at index 0. This is what's normally
+done, but in case transparency doesn't work correctly, you might want to
+check this.
+
+
+(*) 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 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.
git.cweiske.de / enigma2.git / blobdiff