It all remains a design that promotes hardcoded fixed functionality, which severly limits its use.
The data passed to the skin should be the raw data, and any formatting, transforming and manipulation should happen in the skin. This way you can for example create the movie selection title line like so
<element type="language" name="Recorded files..." />
<element type="movielist" name="currentPath" modifiers="basename|format:' * %s * '" />
<element type="movielist" name="freeSpaceBytes" data="currentPath" modifiers="valueToGB|format:'%d GB'" />
<element type="movielist" name="freeSpacePercentage" data="currentPath" modifiers="format:' (%d%%) '" />
<element type="language" name="free disk space" />
where "lang" returns a translated language string, "name" a valid defined in the API, "data" in case the API needs input to detemine which value to return, and modifiers (python functions/methods/language constrtucts) that allows the skin designer to manipulate the raw value.
This way a change can be made from the current system of creating hardcoded renderers and converters for each and every value a skin designer would ever want to display to a set of generic components that can be used time and time again. Adding new modifiers is never a problem for existing skins, and neither is updating the API with a new raw data name.
In the past I've made a PHP template engine to generate emails from templates using this principle, but it applies to skins all the same.
It is simple enough to understand for not-technical-savvy people, in the app I've implemented that system the templates are made and maintained by a department secretary. It just requires a bit of documentation.
Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Ultimate (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)
Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.
Many answers to your question can be found in our new and improved wiki.
