doc/SKINS

   1 enigma2 skins
   2 =============
   3
   4 A skin file is an XML file. Better read the existing skin file as an
   5 example.
   6
   7 colors
   8 ======
   9
  10 you can define alias names for different colors. the "value" is given as
  11 #aarrggbb, or just #rrggbb.
  12
  13 windowstyle
  14 ===========
  15 here you can configure the "window style", i.e. the bord around windows.
  16
  17 screens
  18 =======
  19
  20 these are the different widgets for the screens. they can also be embedded
  21 in the screens itself.
  22
  23 pixmap paths
  24 ============
  25 there is no lookup order, but exactly one place to search for pixmaps.
  26 You can either:
  27  - specify a full pathname (PLEASE, don't!), with a leading slash.
  28  - specify a relative pathname, without leading slash.
  29    The file will be searched for under the default skin image directory.
  30    use this to refer to pixmaps which are included in the default
  31    distribution, i.e. no skin specific stuff but for example the
  32    number bitmaps etc.
  33  - relative to the skin's directory (with a leading "~/").
  34    ~ in this case can be seen as the skin's "home directory", that's the
  35    place where the skin.xml is.
  36    use this if you are building a skin.
  37
  38 A NOTE ABOUT PNGs
  39 =================
  40
  41 Enigma can user either a 32bit argb or an 8bit pseudocolor output. In any
  42 case, enigma uses 8bit PNGs for skins.
  43
  44 Though it would be easy to support 32bit pngs as well, it questionable if
  45 this would be a great idea.
  46
  47 a.) the quality improvement is realative
  48
  49 you can use another palette for each png. that gives you unique 256 colors
  50 for each skin element. Unless you have very big PNGs, you shouldn't be able
  51 to notive the difference between 32bit and 8bit.
  52
  53 b.) 32bit skins wouldn't be compatible to 8bit displays
  54
  55 we still want to use enigma on hardware which is too slow for using a 32bit
  56 output (after all, framebuffers can be very slow). Turning a 32bit bitmap
  57 into an 8bit one is not ease and involves a lot of computations.
  58
  59 It would end up that you need to specify an 8bit and a 32bit version. Is
  60 that really what you want?
  61
  62 c.) 32bit PNGs don't compress well
  63
  64 PNG is a lossless format. 32bit bitmap data is very hard to compress
  65 lossless.
  66
  67 We could use JPG, but jpgs don't offer a transparency channel, as far as i
  68 know.
  69
  70
  71 So, how to make your PNGs to look good?
  72
  73 It's simple. Edit them as 32bit ARGB (photoshop, gimp should be able to do
  74 this fine!). Be sure that if you want alphatest, transparency really has an
  75 alpha value of 0 / 255 (i.e. the extreme).
  76
  77 When you're finished, use "pngquant 256 <filename>" to process your PNGs to
  78 be compatible with enigma.
  79
  80 note:
  81 =====
  82
  83 if you're having less than 16 colors in your png file, pngquant generates a
  84 16color (4bit) PNG, which is not really what we want. Either add more colors
  85 (evil workaround), fix enigma (good idea!) or patch pngquant to
  86 always create 8bit pngs.
  87
  88 transparency:
  89 =============
  90
  91 First, do not mix up transparency with alpha. I agree, both terms refer to
  92 the same thing, but in our case, it's more complicated. As long as we don't
  93 run on accelerated graphic, we need to differentiate between these two.
  94
  95 Alpha, in our context, is the ratio between the video and the OSD. Alpha = 0
  96 means that OSD is completely visible, and no video, whereas Alpha = 1 (or
  97 0xFF, if you express it so) means that there is only video.
  98
  99 Transparency, on the other hand, is OSD-only. When you have a background,
 100 say a color, and you want to blit a picture on it, you can mix the
 101 background with the picture. (*) This allows pixmap with a non-rectangular
 102 shape.
 103
 104 Because of speed reasons, we don't support real alpha blending when not
 105 running with acceleration. Instead, we use alpha testing. This means that a
 106 special color is "transparent", whereas all other colors are not. This
 107 colors *HAS TO BE AT INDEX 0*. As you can't count on automatic palette
 108 merging (it's disabled when the target is 32bit, so you you're not
 109 restricted to 8bit in total, only 8bit per pixmap), you have to tell your
 110 gfx program to put the transparent color at index 0. This is what's normally
 111 done, but in case transparency doesn't work correctly, you might want to
 112 check this.
 113
 114
 115 (*) Note, that, technically, if we start with a alpha=1 background (i.e.
 116 only video), and alphablend on this, we generalized the problem enough that
 117 we can handle both cases the same. But currently, we have to differentiate
 118 between them, as we can't always alphablend simply for performance reasons.
 119
 120 lcd:
 121 ====
 122
 123 Right now, most lcd-skins ("summary screens") are implemented right in the
 124 python screens. However, you can override them with regular skinfiles.
 125
 126 There is some confusion about the actual size of the LCD. For now, assume it
 127 to be 132x64 pixel, but think of the fact that some (most?) hardware can
 128 only display either 128 (dreambox) or 120 (dbox2, dm8000) pixels
 129 horizontally.
 130
 131 Right now some pixels will be cropped, currently at the right side. This
 132 will be (hopefully) fixed soon, so that the used pixels are always in the
 133 center.
 134
 135 So, bottom line:
 136
 137 Design LCD skins for 132x64, with no important items (text etc.) at the
 138 outermost 6 pixels on each side. In doubt, leave them white.
 139
 140 LCD colorspace:
 141 ===============
 142
 143 current LCDs are not able to display grayscale graphics. For this, there
 144 will be a 1bit quantization. However, skins should be designed for 8bit
 145 grayscale (and still look good in 1bit!), because some next-generation
 146 display might be able to display some shades of gray - likely not 256, but
 147 maybe 16 or so.