-
• #2
I've (hopefully) solved my problem with the following hack:
let ScreenWidth = g.getWidth(); let ScreenHeight = g.getHeight(); let AppRect = Bangle.appRect; Bangle.appRect = { x:0,y:0, w:ScreenWidth,h:ScreenHeight, x2:ScreenWidth-1,y2:ScreenHeight-1 };
Before entering a configuration screen, I run the code mentioned above - when leaving it, I simply restore
Bangle.appRect
fromAppRect
.Important note: Bangle.appRect must be set to fullscreen again whenever a new layout shall be calculated/rendered
-
• #3
I believe appRect is automatically pushed down 24px IF there are widgets loaded in WIDGETS. If there aren't widgets loaded then it should return the full screen. For instance:
>Bangle.appRect ={ x: 0, y: 24, w: 176, h: 152, x2: 175, y2: 175 } >reset() ... >Bangle.appRect ={ x: 0, y: 0, w: 176, h: 176, x2: 175, y2: 175 }
The issue really is while you can do what you mentioned to force fullscreen, if a widget updates (eg battery, bluetooth, etc) it'll just redraw over the layout. So realistically the only real way to get fullscreen is to have loaded a seperate app that then never calls
loadWidgets
(since you can't easily unload widgets).Just a note on the settings screen - it looks great, and I know the current
E.showMenu
is not nice at all, but I feel like if at all possible it would probably be good to try and improveE.showMenu
to make it better rather than getting in the situation where every app implements its own settings screens. -
• #4
Well,
showMenu
may use less resources and may be sufficient for navigation and selecting single values out of a short list - but as soon as configuration becomes more complex (and this already begins with the choice of a specific color) or has to offer "Ok" and "Cancel" or even "Preview" opportunities (rather than just a simple "Back"), the menu system becomes really cumbersome to operate. Thats why I started writing components which look familiar for "normal" users.Test person is my wife which does not care at all about technical constraints and efforts, but just wants a system like the Bangle.js to be easily usable - and she currently likes using a Bangle.js 2 although she did not wear any wrist watch for many years
-
• #5
Even though your settings screen looks multitudes better than the regular settings menu, I agree with @Gordon that work ideally should go towards improving
E.showMenu
rather than custom solutions. From a user's standpoint, finding all the different settings in the same place just feels like a better approach.Just my couple of cents though, and to be honest I'm far too engineering orientated to be allowed to say much on how good UI/UX should function.
-
• #6
Yes - just to be clear I'm not saying you should use showMenu as-is. If anything what you're doing is a really good way of figuring out how showMenu maybe should work in the future.
... but longer term I'd like everyone to be able to benefit from that easy usability :)
I'm currently developing a clock with several settings screens.
While the clock is running, widgets should be respected (and the clock face shrunken accordingly), but the settings screens (based on the layout library) should cover the whole screen area.
Unfortunately however, part of the screen appears to not be available (see screenshot). How can I avoid this behaviour?
1 Attachment