You are reading a single comment by @andrewg_oz 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.
@andrewg_oz
I like x1/y1/x2/y2.
After thinking a bit, my phone has widget-like things - but they're only across the top. Perhaps support for bottom widgets should be dropped, and just support "l" and "r" areas ("tl"="bl"="l", "tr"="br"="r"). You've said that few things use bottom widgets. The Bangle 2 could be a good time for a new policy?
I had also been thinking that perhaps the application clipping rectangle could be used (if g.getClipRect() existed and the clipping rectangle was forced to be the non-widget area), but then I thought some apps might like to draw to the entire screen and somehow have the widgets 'float' on top. That would require the application having the responsibility for drawing the background of the widget area, and for the widgets to only draw what they have to without erasing their background. It would also mean that widgets should NOT be calling Bangle.drawWidgets(), but should instead be sending an event to the host application, telling it that the widgets need to be drawn, and allowing it to update the background and then it calls Bangle.drawWidgets().
It also occurs to me that widgets could be dynamic - they could come and go as required, which could mean the entire reserved widget area could also come and go.
For me, the bottom line is this: the host application needs to be able to control where widgets can be displayed and know (if not control) how much space they take up. Widgets also need to know how much space (height) they have. If that is decided to be a fixed 24px height, then I'd be happy with that. If the application knows which widget areas it has enabled, then it can precalculate its draw area at launch - no need for a getAppRect(), but perhaps a need for a getWidgetHeight().