InfiniTime icon indicating copy to clipboard operation
InfiniTime copied to clipboard

App menu stays at second screen

Open minacode opened this issue 1 year ago • 10 comments

Verification

  • [X] I searched for similar issues (including closed issues) and found none was relevant.

Introduce the issue

  1. Go to the app menu.
  2. Go to the second screen.
  3. Press the button to return to the watch face.
  4. Swipe to enter the app menu.
  5. You are still on the second screen.

Preferred solution

I would expect the app menu to reset to the first screen when returning to the watch face.

Version

1.14 (custom, but I doubt it matters)

minacode avatar Feb 07 '24 00:02 minacode

Could you specify your custom fork please? I've had this issue too ever since I've flashed my custom fork onto my watch, so it might actually be the custom fork that's causing this trouble.

tituscmd avatar Feb 07 '24 10:02 tituscmd

It's my simple calculator PR. #1483

minacode avatar Feb 07 '24 10:02 minacode

I have my suspicions that it's due to the compile-time apps, as that was the only time we've changed ApplicationList recently.

FintasticMan avatar Feb 07 '24 11:02 FintasticMan

Yes, probably. I don't understand yet where the state is saved. The information that its the second screen must survive outside the ApplicationList screen, because that gets destructed in between, right? Must be somewhere in DisplayApp.

minacode avatar Feb 07 '24 13:02 minacode

I have my suspicions that it's due to the compile-time apps, as that was the only time we've changed ApplicationList recently.

I have this same behaviour directly in main without compile-time apps specified.

The issue is that the launcher is an "app" in itself with its own internal state. When you press the button, it pops the launcher from the stack and goes back to the watch face. When you swipe down, you're loading the launcher app again, but the screen loaded in the launcher is the same as it was.

The issue is likely the interaction between DisplayApp and ApplicationList. Maybe we need to ensure that the instance of ApplicationList gets destroyed when exiting it?

vkareh avatar Feb 07 '24 16:02 vkareh

Maybe we need to ensure that the instance of ApplicationList gets destroyed when exiting it?

It doesn't? The stack just holds the screen identifiers from the enum, but no whole screen instances, right? Where does the ApplicationList live on after returning to the watch face?

minacode avatar Feb 07 '24 23:02 minacode

Yeah good point. I'm mostly wondering how it keeps the state: the fact that it's on the second screen, rather than back to the initial state...

vkareh avatar Feb 08 '24 14:02 vkareh

The settings have an attribute appMenu. Could that be it? I don't have the time to look deeper into it right now.

minacode avatar Feb 08 '24 22:02 minacode

Oh that's a good find, thanks @minacode! I made a few changes and it seems to work with appMenu. I can try to submit a patch next time I'm at the computer.

vkareh avatar Feb 08 '24 23:02 vkareh

Fix submitted: https://github.com/InfiniTimeOrg/InfiniTime/pull/2009

vkareh avatar Feb 09 '24 13:02 vkareh