On 11/04/2013 07:58 PM, Javier wrote:
TL;DR What would be an appropriate way to monitor the current list of pending notifications in a Lipstick session?

In the older Meegotouch "system-ui" there was the concept of notification sinks. Processes external to system-ui could register [1] a notification sink (ie a D-Bus object implementing a certain interface [2]). All registered sinks were called every time a new notification was received by system-ui or destroyed. This was used by 3rd party programs to e.g. light up a LED every time a notification was received [3] or to forward notifications to MetaWatch [4] and Pebble [5] smart watches.

Lipstick adopts a new API that is closer to the Freedesktop notification API. However, it drops the notification sinks concept. Thus, the above feature is lost except for the compositor process itself, which can just ::connect() to the NotificationManager's signals.

I am trying to figure out if there any alternatives to monitor notifications from an application in Nemo/SailfishOS. My goal is to port my MetaWatch app over to SailfishOS, or even do something more standard such as implementing the Bluetooth 'Alert Notification Profile' or Apple's equivalent ('Apple Notification Center Service') which allow forwarding of notifications to watches and other companion devices.

So far, I've considered a few options:

1) Monitor method calls to org.freedesktop.notifications without actually registering it. This sounds hackish but would be 'compatible' with FDO-compliant notification managers. Things like persistence would be broken, but I'm not sure of how useful persistence is.
2) Monitor Lipstick's SQLite database for changes. Terribly hackish.
3) Add notifications sinks support to Lipstick. As another 'proprietary' extension over the FDO protocol. Trivially, just emitting "NotificationAdded", "NotificationRemoved", ... D-BUS signals would be enough. 4) Does Lipstick accept binary plugins that may access its NotificationManager instance? Would that work in SailfishOS?
5) ??? Some alternate API I've missed.

Also statefs can be used for this purpose, the easiest way is to create inout configuration file, so lipstick can just update an input file and all clients polling output file are be notified.

* configuration file example: https://github.com/nemomobile/statefs/blob/master/examples/config/inout-example.conf * currently existing inout "providers" used for emulation of the system state provided by standard nemomobile providers: https://github.com/nemomobile/statefs-providers/tree/master/inout
* nemo version of timed is using it to publish Alarm.* properties

- denis

Any ideas or recommendations? Criticism is welcome.

[1] https://gitorious.org/meegotouch/meegotouch-systemui/source/src/systemui/notifications/dbusinterfacenotificationsink.xml [2] https://gitorious.org/meegotouch/meegotouch-systemui/source/src/systemui/notifications/notificationareasink.h
[3] http://talk.maemo.org/showthread.php?p=1121878
[4] http://www.youtube.com/watch?v=tD7FisaZsKM
[5] http://talk.maemo.org/showthread.php?t=89890

Reply via email to