InfiniTime
InfiniTime copied to clipboard
Develop: watch face depends on notification status
Verification
- [X] I searched for similar bug reports and found none was relevant.
What happened?
In recent test builds based on develop, the watch face changes not with its setting, but the notification setting from the quick settings.
What should happen instead?
The watch face setting changes the watch face.
Reproduction steps
- Build develop.
- Flash.
- Change the watch face settings and see the watch face doesn't change.
- Change the notification settings and see the watch face change.
More details?
In the setting data, the notification status and the clock face are stored adjacently. Maybe this causes a wrong lookup. The uint8 enum for notification values holds the same values that correspond to the clock face values. I could not find the place where this goes wrong yet.
Maybe refactoring the clock face values into an enum (like the one for apps) gives a type hint somewhere.
Version
develop
Companion app
None.
Could you be more specific on how to reproduce this issue? On my setup, a new watchface is applied when I edit the watchface setting, independently from the "silence" and "sleep" mode for the notifications.
I updated the description. Could it be something with me testing #1294 some time ago? I will try to delete the settings file later and see if it helps.
This is my testing protocol:
- flash 1.10: flawless
- flash develop: bug as above
- deleted the settings file with itd
- after changing the settings the watch crashed (maybe I also swiped back to the clock)
- flash develop: bug is still there
https://user-images.githubusercontent.com/7489786/191566597-204e8462-2f77-44f4-81e9-e949217fca7b.MOV
I solved it: I used the last version of the docker image to build the code. The bug is gone with the new version. It is interesting, that it failed that way.
This issue might have been caused by inconsistencies in Settings.h, especially if you built other branches that changed this file without clearing the old build artifacts. I'm not sure, but maybe files that include Settings.h were not properly rebuilt.
So yes, if you cannot reproduce this issue with an up to date Docker image and clean build environment, I guess we can close this issue.