Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

So you're replacing the mkCal? I looked at the nemo plugin when I found that the disabled calendars weren't recorded anywhere else, but as it looked like it had to be submoduled I didn't pursue it further.

Can you dismiss reminders through that then? I assumed that would be a dbus call.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

No, plugin's dbus service covers only async data fetch, to manage events you still need to submit changes to the storage either via mkCal or NemoCal api.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

So what's the advantage of switching to the nemo plugin? It looks like it brings in a lot of code, or is there a package we can depend on now?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Another way to wrokaround that is to bolck/filter system generated reminders and instead pool in timeline-pin generated reminders which will be perfectly managed by timeline engine internally. They still will be synchronized to calendar - so changes will come up sonner or later to rockpool's timeline, but otherwise they will be independent from system notifications.

I think this should be cleaner solution, even if not that realtime as direct cal bindings.
The benefit is a) automatically picking up disabled calendars, b) fetch calendar events over dbus (no permissions required)

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I thought the nemo plugin still used the mkcal stuff internally, and so still needed the permissions. I'll have to have a look it again. I agree it's more the proper way to do it, especially if Sailfish changes its calendar backend as they were hinting at for the future. Of course by then the QtOrganizer stuff should work, which would be best of all.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

so yes, the plugin itself still sits directly on the storage and hence to submit changes you still need the permissions (to manage reminders for snooze/dismiss).
But the plugin also provides light dbus service which allows you to read all calendar events over DBus async-ly:
fire id=org.nemomobile.calendardataservice.getEvents s:start s:end
and then be ready to catch consequent signals
org.nemomobile.calendardataservice.getEventsResult s:id a(sssssbssss):events

but now as i look at it... the event does not have reminders bundled into it. so we wouldn't be able to block system and use internal :( we then still need permissions - either to fetch full event struct with reminders - or to submit changes to cal storage.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Ok, phase2 target is achieved - I can send canned message back from watches and handle it in the platform integration layer. As a side effect - persistence on a very high level is also implemented.

Now, does anyone know a proper way to send messages? IM and SMS? I hate to use ofono and/or telepathy channels directly, there must be some more appropriate way. Or am I too optimistic re jolla's architecture?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Ofono was the only way I could find to send SMSes. I hadn't found any way of sending IMs yet.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Here we go again :)

https://www.kickstarter.com/projects...y-new-3g-ultra

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

stockpiled quite a big bunch of commits, probably a good time to merge. Posted a beta rpm.
Atm - no (visible) new functionality - except everything timeline related is moved to timeline engine - notifications and calendar.
As a side effect - some colors are changed, some new actions are added, devcon supports pin-insert, there's dbus call to insert the timeline pin, notifications are pooled and re-delivered on connection...
Don't be confused by Canned Response action - it's part of notifcation now however platform part is not yet implemented, so it does nothing except notifying platform part to do the reply.
Next steps - platform part and websync.