Watch faces can now be selected at buid time. It's implemented in a similar way than the selection of user apps, using a list of watch face description that is generated at build time (consteval, constexpr)
A list of "user applications" is built at compile time. It contains all the info needed to create the application at runtime (ptr to a create() function) and to display the app in the application menu. All applications declare a TypeTrait with these information.
When a new app must be loaded, DisplayApp first check if this app is a System app (in which case it creates it like it did before). If it's not a System app, it looks for the app in the list of User applications and creates it if it found it.
Those changes allow to more easily add new app and to select which app must be built into the firmware.
Switch to C++20 (and fix a few issues in SpiMaster.cpp and Watchdog.cpp.
When a notification is received, SystemTask sends messages to DisplayApp, which loads the Notifications apps that sends a few messages to SystemApp.
When notification are received too quickly, DisplayApp and SystemTask cannot process those messages fast enough (probably because of the time it takes to refresh the display) and the message queues fill up. When they are full, the current implementation just waits until there's room available to store the event. In this case, since both tasks exchange messages, they end up in a deadlock.
This fix consists in setting the timeout value to 0 (non-blocking mode) for the NewNotification messages on the DisplayApp side. This will prevent the SystemTask from being blocked (which would result in the watchdog reseting the watch). A more generic approach should be design in the future.
Navigation app now needs 2 images to be loaded from the resources on the external filesystem. This PR adds an 'enabled' field to the Applications struct. This field is true for all applications expect for Navigation which calls Navigation::IsAvailable(). This methods returns true if the 2 files are available in the resources.
The application list disables the application (draws it in grey, disables the touch callback) if the enable flag is not set.
Replace custom FreeRTOS inactivity timers with LVGL inactivity timers.
DisplayApp: Trigger display activity on timer done.
inactivity: Add additional checks
The backlight could be turned on by RestoreBrightness() on ble connect
event.
inactivity: Trigger activity on screen switch
A notification timing out could put the watch to sleep immediately.
While this could be ideal behaviour, it was caused by delay in
processing the EnableSleeping event and pushing RestoreBrightness to
DisplayApp.
Previously, the LVGL driver for the filesystem was initialized in the class FS. However, since 6f942e2, the order of the initializations was incorrect : the driver was initialized (FS::LVGLFileSystemInit()) before LVGL (LittleVgl.Init()), which means that the driver registration was probably dropped when LVGL was initialized.
The LVGL driver is now initialized in LittleVgl.Init(), which seems to make much more sense, since all LVGL drivers are initialized there. This way, we ensure that the initialization of the drivers is consistent.
LVGL is only a part of the main DisplayApp. Other "DisplayApps" can be
implemented without LVGL.
DummyLittleVgl isn't needed anymore and has been removed
Replace separate SettingSetDate and SettingSetTime with a combined screenlist.
Add DotIndicators. Similar to PageIndicator, but for use when separating screens instead of pages of a list.
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
Each opened app (screen) is pushed on a stack, which is then popped from
when returning instead of hard coded "previous apps". Return swipe and
refresh directions are automatically determined from the app transition.
* Reset timer by long pressing on the button
* Consider press_lost as released
Otherwise the bar would keep increasing if the finger slid off the
button
This feature is not needed and is probably more likely to cause issues. It's better to just use brightnessController.Set(settingsController.GetBrightness());
Let the TouchHandler::GestureGet() function return a TouchEvent instead
of the touchpanel-driver specific enum.
This helps to move the driver specific helper function `ConvertGesture`
from `DisplayApp` into `TouchHandler`.
Apply a few changes that were requested in the PR during the review.
# Conflicts:
# src/CMakeLists.txt
# src/displayapp/Apps.h
# src/displayapp/DisplayApp.cpp
# src/displayapp/Messages.h
# src/displayapp/screens/settings/Settings.cpp
For the simulator I need a way to get to the brightnessController object
and handle the set brightness-levels accoringly.
This is done by the constructor expecting a brightnessController object
instead of initializing one itself
