Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

They are not, it's only if we won't package it to the app (either as a .so in rpm or statically linked) - we're limiting potential users to those who can install external dependency (either via ssu/pkcon or otherwise). So this is what we need to crack on - go with external dep or package all together.
Or do you mean in general?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I don't want to bundle anything that's already in or could be in the Sailfish repos - if that QtWebSockets build works then we could request an official backport. That was my intention once we'd managed to test that it works - and it seems like this is the case. I think the next step on that would be a request on TJC or in the community meeting.

In the meantime if we want this to be accessible to all, I think as long as the QtWebSockets packages are available in repos that are already configured, then they'll be brought in as dependencies during upgrade. That means copying them to our repositories, and I'll ask coderus if he's ok with that. It's only polite.

Until then we have a 'dev' edition of Rockpool with this stuff in and the extra instructions to follow. That's really what ruff's beta version is already.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Both executables of rockpool and rockpoold are relatively large compared to some other apps. E.g. harbour-warehouse is ~120KiB. I was just wondering why that is, and hoping it was not due to statically linked libraries :)

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

For the UI it's the watch model image resources in /rockwork/artwork. I'm not sure what's making the daemon so large, but it's not static libs afaik. Rockpool has less embedded stuff that pebbled did. That had quazip statically linked, while Rockpool depends on the Sailfish package instead.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

What are plans for proper timeline implementation? Started looking at how to hook in dev.con pin-ops and found complete absence of the timeline in rockpool. There's some rudimentary glue on top of blobdb to wrap calendar and notification events but otherwise it's empty.

I'm thinking about making something on top of sqlite to handle proper insert/select/update with either raw json or cooked serialized bytearray as a payload.
But this is big chunk of work, so if there's already movement in that direction somewhere else - can patiently wait :) or participate.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

There's insertTimelinePin, which is how the calendar events are inserted, but that's the limit of what the app should be inserting.

I was told that watch apps can't insert pins into the timeline directly, but should use the user's account at Pebble as an aggregator. What should happen here is that the JS app makes a subscription request which is sent to pebble.com and opts the user into pins from that app, the watchapp developers push their pins there, and we pull them all together and insert them into the timeline. That would require an implementation of the login and account token that we spoke about before, and also a proper JSON representation of all pins, including the proper icon URLs. So far all there is for this are the empty methods in JSKitPebble: timelineSubscribe, timelineUnsubscribe, and getTimelineToken, but I think it's on RockWork's todo list as well.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

watchapps yes, but insertTimelinePin is already blobdb operation - i.e. insert into the watch from the phone. But phone-side handler is missing. Even JSKit will just provide a feed of pins, while they should still be handled in the phone (rockpoold).
pebble SDK can do pin insertion (emulate jskit pin being delivered over the net) but it merely delivers json object to the phone (via devconnection).
Now - that json should be parsed, cooked, transformed into TimelineItem(TimelineAttributes,TimelineActions) based on local timeline state (new event/update/delete) and resulting blob pushed to the blobdb. So this is the part i'm talking about.
Again, reference implementation is done by Kath here https://github.com/pebble/pypkjs/tre...ypkjs/timeline

Edit: To make it more clear need to clarify terms: Pin - JSON object as described here; TimelineItem - Binary object which could be serialized and pushed to watch; InsertTimelinePin is that wrapper I was speaking about - lightweight attempt to glue events/notifications to the Time Pebbles by creating TimelineItem on the fly from some input params.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I see. Yes then, that's what we'll need for the last part of what I just described. We'll get JSON pins from pebble.com, and we'll need to transform them. Last time we spoke about this on the ubupebblers group, Katharine said we should be keeping this file out of the firmware pack and using it to validate the fields and find the resource id for the icons:

https://github.com/pebble/pypkjs/blo...e/layouts.json

Then, we should remove the Notification::NotificationType enum and use those URIs instead, as they're what we'll be getting back in the JSON anyway.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

This type afaik is used for internal mapping - to create a pin-like object from platform event, so that might need to keep. What we need to remove though is that part from blobdb where we assign icons based on the type (BlobDB::insertNotification) - maybe move it to notification - so that should be able to cast itself to the TimelineItem.

Ideally platform integration layer should come up with proper json document and just feed it to the timeline engine. In that case we can remove of course all these proxy objects like notifications and calendar-events working purely with the timeine api to manage all kind of notifications. Or with raw TimelineItem - to avoid double conversion (for one-offs).

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

The enum I mentioned is just an incomplete copy of the resources section of the layout.json.auto, mapping icon names to integer ids. Katharine recommended that we use those URIs instead, and that file as the reference as they can be used by any pin source anyway.

Yes, that sounds clean. I think it's best to stick with the JSON - it can be marshalled/unmarshalled by the TimelineItem itself. We'll have to see if the proxy objects can be removed - it would certainly be much easier to implement support for multiple actions in one place - the reminders need a dismissal.

All this is taking us further and further from RockWork though. My last merge request contained JS fixes for app compatibility that must affect them too, but it's been sitting there for almost a month. I had hoped to clean up and trickle the changes back as we went, but at this rate I'll have to hope for a re-merge in the future instead.