Skin, widget, renderer and converter API
This reference is extracted from OpenATV’s lib/python/skin.py and annotated for skinners. The Enigma2 source snapshot defines the documented API. Internal Python interfaces can change in future revisions.
Find a name
Section titled “Find a name”| Reference | Contents | Try searching for |
|---|---|---|
| Skin dictionary | One context-aware index across widgets, XML, central and Python component attributes | underline, scrollbar, font, pixmaps |
| XML structure and templates | Parent elements, context-specific values and XML fragments | name, source, fonts, flags, alpha |
| Attributes per widget | 16 native classes, each with its complete applicable central attribute list, counts and native API | eLabel, ePixmap, eListbox, eSlider |
| Renderer API | 41 module classes: native widgets, extra attributes, input contracts, constructors and methods | RunningText, pixmaps, Progress |
| Converter API | 63 module classes: argument parsing, option maps, properties, inheritance and methods | FrontendInfo, ServicePosition, EventTime |
| Named GUI components | 55 core GUI component classes and helpers, including composite widgets and addons | ScrollLabel, Input, ServiceListLegacy |
| API recipes | Explained XML chains and class-specific argument syntax | WithSeconds, ConditionalShowHide, ValueRange |
| Current XML attributes | 99 current/reserved handlers with purpose, syntax, examples, defaults, supported widgets and limitations | zPosition, alphaTest, padding, widgetBorderWidth |
| Deprecated attributes and migration | 26 deprecated/compatibility names, replacements and value changes | noWrap, selectionDisabled, textOffset |
| Underline text | Label versus template syntax and visibility checks | underline, flags |
| List width and scrollbar | Value-column resizing, ConfigList and the automatic XmlMultiContent path | showOnDemandShrink, last column |
| Functions and value parsers | All 54 top-level functions, signatures and extracted option tokens | parseColor, parseCoordinate, readSkin |
| Classes and their methods | All 10 top-level classes and links to their declared methods | SkinContext, AttributeParser, TemplateParser |
| Source / converter / renderer catalogue | 124 matching module classes from those three source folders | StaticText, ClockToText, Label |
Each page has a local filter. It matches names and explanations without a server request. Clear the filter to show all entries. The handbook search above also indexes these entries in both native language routes; English technical names work in either edition. Every entry links directly to its implementation at the recorded commit.
XML structure is separate from attribute dispatch
Section titled “XML structure is separate from attribute dispatch”AttributeParser is only one part of the engine. Some names are consumed by readSkin() or the global loader before any native widget setter runs:
| Name or element | What interprets it |
|---|---|
<skin> |
Root of a skin resource file |
<screen name="…"> |
Registers a named screen; Python’s skinName selects it |
id on a screen/output |
Selects the GUI or display ID; TV OSD normally uses ID 0 |
<widget name="…"> |
Binds an existing Python GUI component |
<widget source="…" render="…"> |
Resolves a source and instantiates its renderer |
<convert type="…">arguments</convert> |
Adds a converter with class-specific arguments |
<widget addon="…" connection="…"> |
Instantiates a GUI addon connected to named components |
<eLabel>, <ePixmap>, <eRectangle> |
Creates additional decorative native widgets |
<panel> |
Changes a layout context and/or includes a named definition |
<eStack> |
Creates a native stack widget with its own layout behaviour |
condition, conditional, includes, excludes, objectTypes |
Filters elements while the screen is constructed |
Structural names such as name, source, render and type are therefore not missing native setters. They belong to a different parsing stage. A no-op attribute handler can mean the value was already consumed elsewhere; it does not establish a new native capability.
Global skin resources
Section titled “Global skin resources”loadSingleSkinData() handles output, include, switchpixmap, colors, fonts (including aliases), parameters, image mappings for screens/menus/setups, constant-widgets, layouts, variables, subtitles, windowstyle and margin.
These sections configure shared resources or defaults. They are not arbitrary child widgets. For example:
<skin> <colors> <color name="LabText" value="#00FFFFFF" /> </colors> <variables> <variable name="LabMargin" value="24,24" /> </variables> <fonts> <alias name="LabBody" font="Regular" size="26" height="32" width="18" /> </fonts></skin>The Regular face must already be registered. Font alias width/height are layout metrics; they do not measure every string. Variables are expanded only by the parsers that support them. A variable is not a general XML macro.
Read an entry correctly
Section titled “Read an entry correctly”An attribute entry lists the native methods that its handler calls. The per-widget tables resolve those methods through native inheritance and distinguish value branches and overloads. itemHeight is applicable to a listbox; it is not an ePixmap attribute just because the central parser recognises the name. Python components can consume additional attributes or reinterpret central names before dispatch.
Parser fallback values in this reference apply when that parser receives an invalid value. They are not necessarily the default appearance when the attribute is omitted; native widget defaults and the active window style also matter.
The reference records all function signatures and class method names, including internal helpers. Prefer Screen, GUI components and supported skin XML for ordinary layouts. Importing skin.py in a desktop Python interpreter is not a standalone validation method: it requires a running Enigma2 environment.
Version and maintenance
Section titled “Version and maintenance”See verification for the exact source hash and receiver capture scope. The skin.py catalogue parses Python AST; the widget catalogue also reads native C++ public declarations and resolves inheritance. Neither executes receiver modules or converter expressions. Human-written explanations accompany the catalogues; exact constructor/applySkin excerpts retain class-specific argument syntax and defaults.
