In the screens that use `DisplayApp *app` and pass it to a child item,
or use the reference just in the constructor. Afterwards the `app`
member is not used. So remove it from the private member variables.
Completely remove `app` parameter from `SettingDisplay` constructor as
it is unused.
State transitions now happen immediately where possible
This simplifies state management in general,
and prevents bugs such as the chime issue from occurring in the first place
When turning off the screen, if there is no actual app loaded (i.e. we
are still in the Launcher, Notifications, QuickSettings, or Settings
screens) we should just reload the Clock app directly.
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
Add new App `Dice.h` to randomly roll the dice(s).
The number of dice can range from 1-9 (default 1), and the sides can
range from d2-d99 (default d2).
To have a haptic feedback we make Dice vibrate on roll.
Regarding the use of C++ `<random>` library:
There are known problems with `rand()` and `srand()` (see https://en.cppreference.com/w/cpp/numeric/random/rand)
and the `<random>` library is preferred for this reason. The function used from
`<random>` also avoids a very rare bias that would occur using `rand()` and modulo,
when `RAND_MAX` is not a multiple of `d` and the initially generated number falls in
the last "short" segment. This commit also updates the seed to derive entropy
(via `seed_seq`) from a mix of the system tick count and the x,y,z components of the
PineTime motion controller -- taking inspiration from and with credit to @w4tsn
(https://github.com/InfiniTimeOrg/InfiniTime/pull/1199)
Thanks for suggestions:
* in Dice, when rolling 1d2, also show "HEADS" or "TAILS" -- suggestion by @medeyko
* ui adjustments and result realignment -- suggestion by @Boteium
---------
Co-authored-by: NeroBurner <pyro4hell@gmail.com>
Co-authored-by: Riku Isokoski <riksu9000@gmail.com>
Co-authored-by: Paul Weiß <45500341+Poohl@users.noreply.github.com>
Co-authored-by: FintasticMan <finlay.neon.kid@gmail.com>
The list of watch face to build into the firmware is now set by CMake (-DENABLE_WATCHFACES).
Fix SettingWatchFace : convert to index to/from WatchFace when needed.
This new implementation of the weather feature provides a new BLE API and a new weather service.
The API uses a single characteristic that allows companion apps to write the weather conditions (current and forecast for the next 5 days).
The SimpleWeather service exposes those data as std::optional fields.
This new implementation replaces the previous WeahterService.
The API is documented in docs/SimpleWeatherService.md.
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
