InfiniTime icon indicating copy to clipboard operation
InfiniTime copied to clipboard

Develop: watch face depends on notification status

Open minacode opened this issue 2 years ago • 3 comments

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

  1. Build develop.
  2. Flash.
  3. Change the watch face settings and see the watch face doesn't change.
  4. 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.

minacode avatar Sep 18 '22 08:09 minacode

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.

JF002 avatar Sep 18 '22 09:09 JF002

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.

minacode avatar Sep 18 '22 10:09 minacode

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

minacode avatar Sep 21 '22 17:09 minacode

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.

minacode avatar Sep 24 '22 17:09 minacode

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.

JF002 avatar Sep 27 '22 15:09 JF002