Nope, still alive and kicking . Although I didn't do any development in my spare time the last couple of months.


I tried two different routes. Both using direct/"low level" DBus calls instead of creating a QDBusInterface or QDBusAbastractAdapter. I tried using both the more low level/generic oFono (which I used in Kodimote) and the Nemo based Nemo VoiceCall DBus API. I tried both because there is an issue were calling "hangup" on an incoming (ringing) call gives odd results (in most cases the phone (and Pebble) start ringing again and when calling "hangup" on the new call the other end gets a message that there was a problem setting up the connection instead of going to voicemail the first time already). But in the end I sticked with the Nemo VoiceCall API as that one allows muting an incoming call (instead of hanging up), although I didn't implement it. But it's most likely some issue in you're code which makes it crash and not in the API you're using.

Most of it actually isn't that hard and I based it on some code made by javispedro, which can be found here (the agendamanager files). But you'll also need to append a line to some permissions file of Sailfish, otherwise you can't open the sqlite database. How to do this can be found in the RPM spec file of the previously linked repo.


Using Pebbleds code for notification handling is IMHO kinda stupid. This because it uses Qts DBus library to monitor the creation of notifications. But it doesn't allow to "sniff" the notification id which is send in response to the app creating the notification. This means you can't monitor which notifications get closed or updated. So you can't remove or update a notification on the Pebble when it gets removed or updated on the phone (especially annoying when using WhatsApp as I had the Pebble crash/reboot multiple times when removing a lot of notifications using Pebbled). So to be able to get the notifications including its id I used some other code from javispedro, which are the notification files found here.

Getting the individual notifications for new emails (as shown on the events screen) is however fairly easy, as the email app actually sends N+1 notifications when N emails are received. IIRC Pebbled currently uses some ".summary" name/hint to get the notification, but that indeed just contains the "N new emails" text. But the other notifications contain both the sender and subject of the individual emails as shown on the events screen. But those notifications use a different name/hint, which you can easily get by running "dbus-monitor" when receiving the mails and reading the output.

But for the email notifications and pins* I'm not using the notifications at all, but I'm actually using the Qt Messaging Framework (QMF). As this allows to get a (plain text) preview of the email which the notification doesn't contain. And using the library/framework would also be the way to go if you want to support the "respond" actions of the Pebble. As it allows you so create new emails and send them, without opening the email app on the phone.

* For email, SMS and missed calls notifications I create both a pin on the timeline and a notification. This using the timeline spec. So I'm able to fully parse any JSON pin that the Android and iOS apps support and which can be used by other services to push pins to the Pebble. This is possible because Pebble actually publishes the description of the layout (all fields, which attribute id they have, and of which type they are) as part of the firmware update endpoint. And this also allows me to for example conditionally add the "createNotification" field to a pin based on whether the email already has been marked as read or not (when it has been read on another device).
But as far as I've seen the implementation in RockWatch is hardcoded to those supported by it (notifications of a specific type or calendar events). So it doesn't allow the fully dynamic usage of the timeline pins.