[mer-general] [Nemo] [lipstick] Notification Sinks support request

2013-11-04 Thread Javier
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.

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





Re: [mer-general] [Nemo] [lipstick] Notification Sinks support request

2013-11-04 Thread Denis Zalevskiy

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