You are reading a single comment by @allObjects and its replies.
Click here to read the full conversation.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
@allObjects
@Gordon,
I looked at the code changes. Bottom line: introduction of an abstraction layer. Replacing direct display/input control with metadata driven display/input control, where the meta data is the layout, and handling of the display/input is in the layout interpretation code (scaling, etc.).
I can understand the expectation that a scaling (using the templates) can handle the different hardwares. When it comes to screen size with congruency, it may work... but that is about it. I'd rather have the layout being device specific... and, in a 1st phase with templates that are static after construction, and in 2nd phase enabled to dynamically perform some transformations - out of the box as well as custom. Btw, the template constructor has to accept a config or parm object to make it data controlled.
This raises the number of moving parts but makes it much easier to implement, and second adapt to the uniqueness of the devices that cannot be handled by scaling, such as colors, different input, physical limitations, omitted elements, etc. and avoid compromises, better runtime performance in cycles and footprint.
In other words, every app has its (across devices shared) core components (file(s)) and some complements that are device specific. On application (down)load/install, the shared core components are loaded and then only the device specific one/s is/are loaded.
After having built the espruino.com/ui (more - pics - at Modular and extensible UI framework and ui elements) for 240x320 262 Colors TFT w/ touch screen, I tried to adapt it to non-touch screen - just buttons - and then to Pixl.js, I come to this conclusion / recommendation: rather draw the line tighter on 'auto-adjust to underlaying hardware / constraints' and provide a support system to handle the efficient, hardware specific/dedicated components, then avoid device specific components and do everything automatically. This approach allows also an easier life cycle management, because at one time Bangle.version x-n phases out and Bangle version x+m joins the family, and bangle.version x-n support can be dropped without code change, and version x+m can gradually phase in with apps of interest get the device dedicated components built on demand.
It is also much easier to write a display/input emulator to develop and verify the device specific compoents.