feat(ui): create permanent notification - allow notifications
Description
Sometimes we need to display a notification in a “permanent” way (aka, not automatically closed after a timeout).
The main idea is to have a dedicated notification that can be controlled afterward, with specific signal / slots.
We may also want to modify the content, allowing to reuse them instead of close them and reopen new ones.
Functional specifications
- Create a notification that could remain displayed (no timeout), be updated, and is only closed with a specific signal, or when an application is closed.
Technical specifications
- Create a new interface dedicated to notification (INotify)
- Move all related signal, types, struct from IService to INotify
- Inherit from INotify in all service that needs notifications.
- Modify
INotify::notify(type, std::string message)
API ->INotify::notify(type, std::string message, std::optional<std::chrono::duration> = 3s, std::string channel = "")
-
channel
(default = ""), to identify uniquely a "notification". -
channels
will be configured in XML:<notifications> <channel key="Connection" uid="${info_zone}" /> <channel key="Tracking" uid="${tracking_zone}" /> </notifications>
- XML
channels
will be mapped when callingINotify::cofiguring()
- add a
std::optional<std::chrono::duration>
parameter tonotify()
:- Default to 3s (same as
SNotifier
), -
std::nullopt
means: infinite time -
SNotifier
configuration may override this
- Default to 3s (same as
- add
closeNotification(std::string channel)
to close a specific notification.
- Modify
SNotifier
to match new API
- Add missing signals / slots
- Manage duration from new notify signal
- Keep a map with the handle as key
-
INotify
destructor (stop?) should take care of removing still displayed notification
-
notified
signal should also send the pointer / id of the service ?
We should also make sure that:
- “Permanent” notifications should be closed by simple/double click
- Notification should be closed when the service that emitted it is destroyed (stopped ?)
In The notification itself:
For the “permanent” mode, we should use a very large timeout (4 days ? max of uint64 ?)- Optionnaly add a dedicated qss, or a graphica effet (halo, slow blink ?)
Test plan
To be defined, but at least a test in ExNotification. Dedicated gui test should be the best!