2v16 Bangle.setUI

Hi,
We've recently bought a new batch of 'Bangle.js 2' devices. These are programmed with our application in the production department of our company and, to our surprise, the application failed on all devices. Font sizes were wrong, dark/light theme switching did not work, etc...

After a day's worth of debugging, I tracked this down to a change in 'Bangle.setUI()' which now seems to reset the Graphics object to its default state. This means that after every call to setUI(), one needs to re-initialise the graphics engine (in my case : g.setFont, g.setColor, g.setBackground, g.setFontAlign, ...).

Our application uses setUI() a lot because, depending on the display mode, different touch gestures are used (and thus distinct callbacks are often removed/registered).

Is my analysis correct ?

If so, may I ask that, in future firmware releases, such large changes are implemented in a new method (e.g. Bangle.setUIAndReset() ?) so that these do not break existing applications?

Thank you.

Maybe this helps to work around:
https://forum.espruino.com/comments/1614­9905/

Hi,

Sorry to hear that's caused you problems, but yes - that sounds like it's the problem.

Generally I try extremely hard to avoid breaking anything with firmware updates, but with normal Bangle.js apps we have widgets and other things that can draw to the screen at any time. Code that draws generally has to set the state from scratch each time, and it's usually recommended that any draw code calls g.reset() before anything just to get things to a known state. Adding it to setUI was a way to make things more reliable as some subtle bugs had cropped up because the rendering state changed in some circumstances.

It's unfortunate this happened, but it's basically impossible for me know if there will be side-effects in code that is completely private I'm afraid.

would having some graphics context save/restore/push/pop methods make sense in such cases? so one would not need to call g.setFont, g.setColor, g.setBackground, g.setFontAlign, ... over and over again?
not sure how hard it could be to implement, maybe some memcpy of some structure. could save some time when drawing to screen in multiple repeating styles

Yes, I had wondered about that - potentially a Graphics instance could be cloned so state could be kept in different places but there are potential problems there (like keeping track of the modified area).

I think at the end of the day it's better to keep things simple. I think push/pop in particular would almost certainly end up causing far more bugs than it fixed.