-
Since I'm currently working on a 2FA app, I've been thinking about exactly this (along with wondering if there is some sort of theme API for default colours).
Should it be the app getting the available space from the system? Should there be some way for the app to control how much space is available for widgets? Top only? Bottom only? Both? More or less than 24px?
Maybe the API should be:
- Bangle.getDefaultWidgetHeight() - returns 24 - this could be device dependant?
- Bangle.setWidgetHeight(top, btm) - set height of top and/or bottom widget space
- Bangle.getWidgetRect() - get effective screen area left after widgets - not necessary? - the app should be able to calculate this?
Then widgets need a new API to determine how much space is available to them! :-)
Also, I think that 24px top + 24px bottom (48px total) out of 176px height available on the Bangle 2 is more than 25% of the total screen height! IMO, that's too much.
- Bangle.getDefaultWidgetHeight() - returns 24 - this could be device dependant?
-
I've noticed in the Bangle 2 emulator that when dragging off the top or left of the screen, the x/y coordinates become 255/253/252/etc - suspiciously like negative numbers cast to 8-bit unsigned integers.
Dragging on/off at those borders also produces spurious very large negative dx/dy values, probably due to the above issue.
Should I report this on the github tracker, or will here do?
-
-
SHA1 is available in the emulator, but SHA256 and SHA512 (and SHA384 and SHA224) are not.
From looking at:
it looks like the Bangle is just getting the JS version of SHA1.
What are the chances of getting SHA256 and SHA512? I'm looking into developing a 2FA app for my Bangle 2 and would like to support all the options.
-
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().