Ticket #393 (closed defect: fixed)
We need a notification API
| Reported by: | alphaone@… | Owned by: | alphaone@… |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | openmoko-libs | Version: | unspecified |
| Severity: | major | Keywords: | |
| Cc: | buglog@…, thomas@… | Blocked By: | |
| Blocking: | Estimated Completion (week): | ||
| HasPatchForReview: | PatchReviewResult: | ||
| Reproducible: |
Description
We need a general API to signal different events to the user like incoming SMS,
low battery or even incoming calls.
This should be realized as an (initially invisible) panel applet that displays
icons according to the events and popup notifications.
A DBus interface is necessary for communication.
There is libnotify that already implements some of these features in Ubuntu.
Maybe libnotify can be used on openmoko, too.
Change History
comment:3 Changed 6 years ago by thomas@…
Libnotify is not an Ubuntu project. It is now being used in many distributions,
and is even slated for inclusion in Maemo.
comment:5 Changed 6 years ago by alphaone@…
- Owner changed from mickey@… to alphaone@…
I meant Ubuntu is already using libnotify nicely to inform about new updates,
etc. Sorry for the confusion.
I'll start working on this now.
comment:7 Changed 6 years ago by alphaone@…
notification-daemon really seems to be what we want to use here, but
it is missing some functionality:
We want the notifications to have an icon present in the panel as long
as the notification is active (even when the actual notification popup
has expired.
i.e. a message arrives: A message icon should appear in the panel and a
notification popup informing us about the Sender and providing buttons
for specific actions ("Read now", "Read later", "Delete"). After 10 seconds
the nofification popup should disappear, leaving the message icon in the
panel. If I click on the message icon the notification should pop up again.
If I read the message through the regular application the icon will disappear.
These are the unobtrusive notifications. We also want to have notifications
that the user *has* to react to.
This would be suitable for most users in case of an incoming call.
Which type of notification is used needs to be configurable by notification
metadata (category, urgency, appname).
