Backlight bug

Hmm, interesting. So this happens regardless of the app being used as long as it's a widget?

Hmm, interesting. So this happens regardless of the app being used as long as it's a widget?

No, it happens with a widget that is turning on the backlight with a call to Attention.backlight(true).

IMHO, it's up to the widget to turn it off, and it shouldn't go by the timeout. Let's say the widget had the option to turn on or off the backlight. You go to the widget, turn it on, do what ever, swipe to the widget, and turn it off. If you want the BL with a timeout, you can just press the backlight button. The widget would allow you to override the timeout.

I'll look into this. On one hand, I agree with jim_m_58, but I also think we should have a contingency for the backlight being left on like this. I'll reproduce the issue and get it reported for consideration.

I don't think you can leave it to a widget to turn the backlight off, even if the widget turned it on (or rather, ensured it is on - as we can't tell if the backlight was on or off before we forced it on). Consider the situation of widget turns on backlight, then there is user activity and user exits widget or we are auto-reaped: should we turn off the backlight as we are unloaded? That would mean that the watch could go dark during user interaction, which is exactly what the user would not want.

I have to say that the more I work with this platform, I really don't understand why widgets are auto-reaped: why not let a user keep a widget open continuously? And why the difference between widgets and watchfaces? Seems to me that a widget should be able to elect the power level switching (min vs second update), and a watchface should really just be the 'preferred' or home widget in the widget carousel. With the current approach to the UI, there are many tools that really need to be provided in all three forms: interactive total-control app, quick glance widget (because it's quickly accessible from the carousel), and always-on watchface. Would be much simpler to just have widgets and apps (and datafields - but that's a whole other subject).

When the widget turns on or off the backlight, it could save what it did in it's object store, and the next time, do the opposite. (if it had turned it on before, turn it off this time, and v/v)

It would keep it's own state of what it thinks the backlight state is. (though there may be times that it's state is wrong)

Widgets are meant to be "quick view" type things, and if you want something to hang around, you can make it a watch-app. In both cases, it's only running if it's what you see on the watch - you can't run in the background.

Widgets and apps have far more access to data than watchfaces (GPS, sensors, etc), and aren't restricted to the low-power mode of watchfaces. Also, watchfaces don't allow any input. Watchfaces are designed to be as low power as possible, as that's what's running much of the time.

When the widget turns on or off the backlight, it could save what it did in it's object store, and the next time, do the opposite. (if it had turned it on before, turn it off this time, and v/v)

It would keep it's own state of what it thinks the backlight state is. (though there may be times that it's state is wrong)

First, no need for the object store - a variable is sufficient, given that once the widget is unloaded, it would be very wrong to assume anything about the backlight state.

Second, if the widget turns on the backlight, the only way it would know that it should turn it off would be to trap all user interaction, etc, to know that on reaping there has been no user input (auto-reap), and thus the light should go off. Think about it - the widget is more likely to get it wrong than right.

Widgets are meant to be "quick view" type things, and if you want something to hang around, you can make it a watch-app. In both cases, it's only running if it's what you see on the watch - you can't run in the background.

Widgets and apps have far more access to data than watchfaces (GPS, sensors, etc), and aren't restricted to the low-power mode of watchfaces. Also, watchfaces don't allow any input. Watchfaces are designed to be as low power as possible, as that's what's running much of the time.

Yeah, I read the docs and have lived with the watch a bunch; I understand these statements. But it seems an artificial distinction that doesn't benefit the user, and I don't see a technology justification for it, either.

Consider implementing a few gauge faces for flying: an artificial horizon, an altimeter with rate of climb, compass, etc (each is a full screen view). We could do this as a flying app and totally control the watch, but that locks out all other apps / widgets / displays while the flying app is running - and it's several button presses to enter and exit our app. But if we implement these as independent widgets, we can make them easily accessible on the carousel; the user can flip through them quickly. Unfortunately, the watch keeps reverting to the watchface after some (platform-dependent) interval - and the user can't control that. Much better if these are implemented as widgets that can vary their update interval (which widgets can do now) and be sticky, so that the user elects when to go back to the 'home' watchface. The carousel is a really nice feature for cycling between relatively lightweight (relatively) stateless apps - why make them time out, and isn't a general watchface just another (relatively) stateless gauge face (with the distinction that one watchface is "most loved")?

I'm curious what your back light timeout is set to. I haven't been able to reproduce this because the widget timeout is longer than the longest back light timeout on the fenix 3. I'm still confirming what the intended timeout is supposed to be (it's currently around 2 minutes, which seems excessive to me). I've tested on several firmware versions, including 5.00, 5.10, 6.50, and an internal develop build that's more recent than 6.50. All behave the same.

I'm curious what your back light timeout is set to. I haven't been able to reproduce this because the widget timeout is longer than the longest back light timeout on the fenix 3. I'm still confirming what the intended timeout is supposed to be (it's currently around 2 minutes, which seems excessive to me). I've tested on several firmware versions, including 5.00, 5.10, 6.50, and an internal develop build that's more recent than 6.50. All behave the same.

My backlight timeout is set at 15 seconds, much shorter than the widget timeout (which I agree is approximately 2 mins). The problem occurs with a widget that turns on the backlight every time the real time clock minutes roll over - so backlight goes on for the first 15 seconds of each minute. If the widget is auto-reaped within the first 15 seconds of a minute, the backlight will stay on until the proverbial cows come home to roost.

Thanks for looking at this.

Maybe I'm misunderstanding what you mean by "auto-reaped". I had read that to mean the widget timeout, but it sounds like you may be referring to something else.

If you are talking about the timeout, then I could have a widget that activates a back light close to the end of the widget timeout (<15 seconds prior), and that would recreate it, correct?