Introduce a restricted clock-only-mode when not woken with the button

[tgc-dk]

To avoid random touches ends up changing settings or starting a timer, this introduces a restricted mode where no touch input is accepted unless the hardware button is used to turn on the watch. ~~A settings is introduces to enable this.~~ ~~The restricted mode is only active on watchfaces.~~

This is not a perfect solution since it will require the button to be pressed several times to leave the restricted mode once in it.

---

edit 2025-05-24: updated description by @NeroBurner :

When the device is woken through pressing the button everything is the same.

But when woken through other means like single-tap or raise-to-wake, then the screen is locked (and showing a lock screen on touch input) until the button is pressed.

Only exception is when the alarm wakes the screen, then touch input is still valid for the user to be able to press the red "stop alarm" button.

[minacode]

The restricted mode is only active on watchfaces.

Why is this necessary? Wouldn't this feature be useful regardless of the active app?

[tgc-dk]

The restricted mode is only active on watchfaces.

Why is this necessary? Wouldn't this feature be useful regardless of the active app?

The reasoning is that if you (for example) are playing the "2" game and the screen goes to sleep due to no activity, if you then wake up the screen by shaking your arm, touch input will be ignored and if you push the hardware button you will exit the game, loosing the progress. One way to solve this is of course to make the first hardware button push unlock the restricted mode, but IMHO this would probably be a bit confusing for users since it would change how the button-push is handled depending on how the wakeup was done...

[minacode]

I think this is exactly how this should be done. The watch goes into a lock mode where the first button press does nothing but exiting that mode. Maybe we could have a popup with a lock symbol and something like "press the button to unlock" on touch events so users can better understand what is going on.

Another thing is a lock screen. We could always show the watch face on non-button wakeup (with a clue that this is a lock screen) and after pressing the button go back to the current screen. This is closer to what other devices like phones do.

[taukakao]

I agree with @minacode although I don't think a real "lock screen" makes sense. Maybe a visual indicator but a lock screen for a watch that only has a couple of modes is a bit much.

One reason I prefer it is because it enables you to have for example the navigation or timer app open on the watch and look at it from time to time. Right now this would always randomly switch to different watch faces on it's own.

[taukakao]

And because I know it will be mentioned: No, I don't think this is a weird workaround for the issue of a too sensitive touch panel. This is for when you currently don't want to interact with your watch but still look at it.

[tgc-dk]

Thanks for the into @minacode and @Joheyy! I'll look into the possibility of implementing a "pop up" notifying about the lock and that the hardware button should be used to unlock.

[minacode]

Keep in mind that the watch can wake itself (for example via notifications).

[tgc-dk]

I've just pushed a new commit that adds a 'Popup' notification and display it when a touch input is received during 'locked' wakeup. The lock is now active on all screens, though not when an app as caused the wakeup. I have only tested this in the simulator so far... Let me know what you think! I've attached a small animation that shows the lock in action.

[Avamander]

That approach seems good, also very similar to that of say Apple Watch.

[minacode]

I like it.

Can you explain the intuition behind the three WokenBy values? Button explains itself, but what exactly are WakeUpAction and Other? What cases do and don't they cover?

[tgc-dk]

Can you explain the intuition behind the three WokenBy values? Button explains itself, but what exactly are WakeUpAction and Other? What cases do and don't they cover?

The WokenBy values are:

• Button: Pretty self explanatory as you say)
• WakeUpAction: The actions selected in the wakeup settings, single/double tap, raise, shake
• Other: Other things that can wake the watch up, basically apps and notifications.

In reality it might be possible to replace the values with a simple boolean wokenByAction, but I'm not yet sure...

[minacode]

I would like that in a comment, in the code. Or better names, I don't know. UserButtonWakeup, UserNonButtonWakeup, SystemAutoWakeup? Sounds weird as well..

[tgc-dk]

I think it would be a good idea to move the popup to displayapp and use displayapp/Messages.h to communicate between the systemtask and DisplayApp

Changed as suggested

[github-actions[bot]]

Build size and comparison to main:

Section	Size	Difference
text	378460B	1460B
data	996B	56B
bss	58444B	-5096B

[pipe01]

Any updates on this?

[tgc-dk]

I've introduced a second page to the WakeUp settings since there was no room left for new checkbox. Note that the CI simulator build fails due to changes needed in InfiniSim to build with the changes in this PR, see InfiniTimeOrg/InfiniSim#131

@NeroBurner Are you up for a re-review?

[riban-bw]

I've just pushed a new commit that adds a 'Popup' notification and display it when a touch input is received during 'locked' wakeup. The lock is now active on all screens, though not when an app as caused the wakeup. I have only tested this in the simulator so far... Let me know what you think! I've attached a small animation that shows the lock in action.

The popup seems rather intrusive. If we are trying to avoid activity that occurs fairly frequently then it is possible that the popup will obscure the display when the user wants to view the watchface. Could we just use a lock icon instead? This is a user configured feature that would probably be disabled by default so the user must enable it and therefore shoudl understand the purpose of the icon. (It could be reinforced by showing the same icon in the settings screen.) The lock icon could show in a notification space, e.g. top of screen. It could either be always visible when locked, shown on activity or visible and highlight on activity. This may also reduce the memory increase. (One icon may be less than lots of text?)

I really like the idea of a lock mechanism (as I too suffer the issue of unexpected activity) but don't want something obscuring the screen.

[NeroBurner]

I'm in favor of the lock as it doesn't need to be translated and should be easily understood. I like the visual hint to use the lock in the setting screen as well

[jgonyea]

I also would love to see this feature added. I don't know how, but I constantly am waking the screen and accidentally tapping on screen elements. This would solve this issue for me!

[tgc-dk]

@riban-bw

The popup seems rather intrusive. If we are trying to avoid activity that occurs fairly frequently then it is possible that the popup will obscure the display when the user wants to view the watchface.

Please note that the lock screen first shows up after the screen has been woken up AND a touch gesture has been identified, meaning that the lock screen does not automatically show when the display is on.

@riban-bw @NeroBurner

I'm in favor of the lock as it doesn't need to be translated and should be easily understood. I like the visual hint to use the lock in the setting screen as well

This is a valid point, I'll change the lock screen to use an actual icon. Regarding using the lock in the in the settings, how do you envision this to be done? See the screenshot below for the current settings screen, shown is the (new) second settings page under "Wake Up". Where should the lock icon be placed?

The lock icon could show in a notification space, e.g. top of screen. It could either be always visible when locked, shown on activity or visible and highlight on activity.

If I understand you correctly, this would be nice, but it would require that InfiniTime has a global notification bar for it to be consisted across screens, which it don't, so I think I'll stick with the pop-up for now.

[tgc-dk]

@NeroBurner @riban-bw Using the popup with a lock icon could look like this:

[jgonyea]

Could it also have an arrow pointing to the crown button to indicate how to unlock?

On Sat, Jan 27, 2024, 16:11 tgc-dk @.***> wrote:

@NeroBurner https://github.com/NeroBurner @riban-bw https://github.com/riban-bw Using the popup with a lock icon could look like this: InfiniSim_2024-01-27_220733.png (view on web) https://github.com/InfiniTimeOrg/InfiniTime/assets/1773050/ba6d0933-867f-452a-856f-93a528b4347e

— Reply to this email directly, view it on GitHub https://github.com/InfiniTimeOrg/InfiniTime/pull/1359#issuecomment-1913336923, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAICFIIU5BA6YKZT2O2UPUDYQVUPHAVCNFSM6AAAAAAQ53RW2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGMZTMOJSGM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[NeroBurner]

This looks perfect ( in my commandline-progrmmers opinion 😁)

I wouldn't require a pointer as this would make it more complicated (with regards to screen orientation on other supported devices)

[NeroBurner]

Regarding the setting and how to put a lock icon in there. No idea. Not enough space in that line. So I'd say keep it like it is now

[tgc-dk]

@NeroBurner Turns out the new lock icon takes up to much spaces so linking fails. See https://github.com/InfiniTimeOrg/InfiniTime/actions/runs/7688311260/job/20949380052

So I've reverted the icon changes...

Suggestions for how to proceed?

[minacode]

Could you use an external font for the icon? Or a smaller icon? 😄 Or draw the lock manually with LVGL somehow?

[mark9064]

If you check the build logs, the difference in RAM usage is just 64B. It's just that infinitime is very close to the memory limit right now - keep the lock change but decrease the heap size a little

[tgc-dk]

@mark9064

If you check the build logs, the difference in RAM usage is just 64B. It's just that infinitime is very close to the memory limit right now - keep the lock change but decrease the heap size a little

Just to be sure... Would I be right in assuming this can be done by in src/FreeRTOSConfig.h changing configTOTAL_HEAP_SIZE from (1024 * 40) to (1024 * 39) ?

[minacode]

(1024 * 35) was recommended before by JF to me for the calculator app.

[tgc-dk]

Pushed the new changes. The simulator build still fails due to dependent on changes in InfiniTimeOrg/InfiniSim#131