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 
a notification sink (ie a D-Bus object implementing a certain
interface ). 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  or to forward notifications to MetaWatch  and
Pebble  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
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:
* currently existing inout providers used for emulation of the system
state provided by standard nemomobile providers:
* nemo version of timed is using it to publish Alarm.* properties
Any ideas or recommendations? Criticism is welcome.