Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App menu stays at second screen #2006

Closed
1 task done
minacode opened this issue Feb 7, 2024 · 10 comments · Fixed by #2009
Closed
1 task done

App menu stays at second screen #2006

minacode opened this issue Feb 7, 2024 · 10 comments · Fixed by #2009

Comments

@minacode
Copy link
Contributor

minacode commented Feb 7, 2024

Verification

  • 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)

@tituscmd
Copy link
Contributor

tituscmd commented Feb 7, 2024

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.

@minacode
Copy link
Contributor Author

minacode commented Feb 7, 2024

It's my simple calculator PR.
#1483

@FintasticMan
Copy link
Member

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

@minacode
Copy link
Contributor Author

minacode commented Feb 7, 2024

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.

@vkareh
Copy link
Contributor

vkareh commented Feb 7, 2024

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?

@minacode
Copy link
Contributor Author

minacode commented Feb 7, 2024

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?

@vkareh
Copy link
Contributor

vkareh commented Feb 8, 2024

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...

@minacode
Copy link
Contributor Author

minacode commented Feb 8, 2024

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

@vkareh
Copy link
Contributor

vkareh commented Feb 8, 2024

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 added a commit to vkareh/InfiniTime that referenced this issue Feb 9, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes InfiniTimeOrg#2006
@vkareh
Copy link
Contributor

vkareh commented Feb 9, 2024

Fix submitted: #2009

vkareh added a commit to vkareh/InfiniTime that referenced this issue Feb 12, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes InfiniTimeOrg#2006
vkareh added a commit to vkareh/InfiniTime that referenced this issue Feb 12, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes InfiniTimeOrg#2006
vkareh added a commit to vkareh/InfiniTime that referenced this issue Feb 14, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes InfiniTimeOrg#2006
vkareh added a commit to vkareh/InfiniTime that referenced this issue Feb 19, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes InfiniTimeOrg#2006
JF002 pushed a commit that referenced this issue Mar 12, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes #2006
Schweini07 pushed a commit to SleepTracking-for-PineTime/InfiniTime that referenced this issue Mar 18, 2024
This prevents the application list from loading in the last used screen
and instead goes back to the first screen whenever the watch face is
loaded.

Fixes InfiniTimeOrg#2006
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants