Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I still have a general problem with some JS apps that are using the status constants in XMLHttpRequest - for some reason they always seem to be undefined no matter what I try. Misfit seems to still be broken because of this, and I hope Trello will be the same.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Here's a request: I'm a bit stuck with the language files. I know where to get them from, but I have no idea how to upload them to the watch. I've tried the existing uploadFile and even tried system resources, but just get NACKs from the watch. If anyone is set up to watch the android app do it, could you tell me what goes on during language file upload? I don't have an android device to try.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I've got an Android tablet and some spare time, so if you can explain how to do it (or link to the right docs, assuming it's easy enough to figure out)...

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Are you getting nacks starting from the very first packet (initialization) or for consequent data? i.e. the former would look strange as it means any upload should be failing, while the later is logicac if we're not using proper upload->type - eg. pebble just cannot parse incoming bytes in accordance with specified type and hence is failing and nacking the transfer.
I presume you've been trying with UploadTypeSystemResources? Did you try feeding the file to pbpack tool to check whether it's in proper binary resource format pebble understands?

I tried File and SystemResources. Have to manually calculate the CRC because it's not in the file, but I think it's right. I get the NACK after the upload is finished.

The timeline pin stuff is looking really good! That's exactly how Katharine said it should be, especially if we fetch the layout json from the pbz when we upgrade.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Try to enable DevCon and use pebble logs -vv --phone <phone.ip> to get live log feed. It also prints out pebble logs which it receives by eavesdropping watch connection - so maybe it'll spit out some clue.

The timeline - am currently working on the PoC phase2 - which is to create persistent pins (and storage). Once done - will move calendar events from CalendarEvent to json pins. As well as moving to nemo-qml-plugin-calendar (as hinted in the organizeradapter.cpp).
Phase3 will be to create authentication and finally websync.

With this in mind - can I ask for a change freeze on the notification/calendar mechanics while I'm slashing the sources?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Great, thanks. I still haven't really looked into the DevCon thing, I'll give it a try.

I was already waiting for this change before doing anything on the notifications or any other timeline bits. Everything I want to try requires more actions than are currently supported. I've also delayed any more pushes back to RockWork until this is done and all the vestiges cleaned up because I've got a feeling it'll be a lot simpler afterwards.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I bet it's about canned messages? %) I'm also itching to inject the actions - that's why i'm currently reworking action handlers (as part of new pin engine) and only then planning to finish persistence

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Dismissing and snoozing reminders too! Are they included?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Partly and not correctly, but the thing is that calendar reminders are system generated, so to snooze/dismiss system calendar reminders you need to snooze them in system calendar. And that part is completely missing in current implementation. That will be bound the the calendar migration to nemo-plugin-calendar - eg. (NemoCalendarEventModification::setReminder(NemoCa lendarEvent::ReminderNone))

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.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

while playing with this response action realized we don't have any voice support whatsoever, implementation for endpoint 0x2af8 is completely missing

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

That's looking really nice, huge drop in code complexity here. A merge as soon as you're ready would be good - I don't think we should release it until the websync is there as users won't see any benefit (though beta is essential). I'd like to help with the plumbing though. I reckon this will be a good time to drop 1.0.

It'll need pebble.com login too for the websync, right?

One thing at a time! :P

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Sure, it's just to reduce review volume later on one side, and get rid of an urge to fix something backdate on the other. While nothing wrong with that per se, it also affects reviewability of the change set.

Yes, it would need oauth token from pebble.com.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Absolutely, just to mark it somewhere till i remember that. Realized then there's better place to leave such reminders - issues board :)

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

crap, attempted to pledge for core - refuses my card. to hell with it.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Is there any way I can hook Saera into the voice things?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I don't yet understand fully how it works, but since there's word AudioCodec (speex) I assume that certain phone app should do actual recognition and submit results. And I don't think we have a big offer of speech recognition services on jolla :)
Voice session setup request looks like this:

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Saera is about the only option we have, because I think we can agree that Sailfish and cloud-based speech recognition are not morally compatible. Maybe I should pledge for a Pebble 2 so I can at least test it :)

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Another way would be using telepathy.
This is the one I've been trying to explore and think should be more appropriate as it allows:

a) step up one abstraction above phone implementation
b) use common interface for SMS and IM messages
c) it automatically adds messages to the comhistoryd - visible in messaging centre.

There was an issue though that only one consumer could be attached to Tp::account as it uses static member internally. However it seems (partially) this was fixed.
nemo-qml-plugin-messages is an example how it works.
Here's an example - https://talk.maemo.org/showthread.php?t=95876
You can get directly to the channel for the phone as it is hardcoded mostly (ring/tel/ring), but IM accounts should be properly discovered based on notification data (from that base64 encoded VariantMap in the x-nemo-remote-action-default) using appropriate telepathy management interface.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

That was the essence of my previous message :)

So taixzo - while we're all here - can you briefly introduce us into interaction with your product? DBus calls? API?
I.e. can we just dump raw speex to /tmp/blah and signal Saera to perform recognition of the dump, then catch another signal in return and forward results to pebble?

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Saera uses libjulius for voice recognition. It can take in data in two ways: via pulseaudio (what Saera uses by default) or reading from a wav file. So, either it needs some sort of pulseaudio bridge (not sure how that would work), or something to transcode from speex to wav. If there's a simple way to do the latter, I can add dbus signals to do recognition on it.

Edit: Saera does not have any api or dbus interface, yet, mainly because up til now nothing needed to communicate with it. I should probably make some sort of plan for how it will work.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Been killing this day by cracking on various flavours of tokens used in pebble terminology, so while it's all fresh in my head will try to put it here (at least my current understanding of it)

Watch Token - Watch/App specific unique token. Watch/App means it is unique per hardware piece (watch) and software piece (app) - i.e. each app will get own version of the token, but the token will be the same if you install/remove/install app. To put it simple - it's hash of the app UUID and HW Serial.

OAuthToken - this is simple. This is authentication token generated once user logged in. Pebble uses long-living (not expiring) tokens so one may safely stash it and use whenever needed. As an example - Pebble SDK uses it this way. Can be obtained at https://auth.getpebble.com/oauth or https://auth-client.getpebble.com/en_US/ with appropriate pebble:// schema handler (eg. gecko in rockpool)

Account token - this is more tricky and more simple. This is unique user ID. It will be the same whatever number of times you generate new OAuthToken. Really - just pebble account id. Can be obtained from https://auth.getpebble.com/api/v1/me.json with proper OAuthToken.

Timeline Token or User Token - this is a User/App specific unique identifier. It is available via locker API when installed app is registered at the locker (with proper OAuthToken). The token is required to manage Timeline subscriptions. Can be obtained at https://api2.getpebble.com/v2/locker/<AppUUID>

Timeline Token or Sandbox Token - this was the most confusing. It appears to be same as above but for apps which are not yet published to the store, rather just hanging at the dev portal. So the function is the same, usage is the same, principle is the same - just allows one (developer that is) to use timeline without publishing the app to the store (but still publishing at devs.portal). Can be obtained at https://timeline-sync.getpebble.com/v1/tokens/sandbox/<AppUUID>

phew. gone sleeping.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Still itching regarding canned messages.

So basically to confirm - telepathy works and works as I described (leaving sent message in comhistory)

both elements - gabble/jabber/google_2dtalk_6 & dev.null@gmail.com are part of notification, so are available in platform stashed notification for canned reply.
Now just need to compile that alltogether

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Found a conflict in documentation. So here's excerpt from JSkit API docs:
while here it states which contradicts a bit with the above. Even though later is not official documentation it sill hints that accountToken is anonymized.
In the end I think the truth is in the middle and it should be safe to make accountToken a hash of the me.json->id + appinfo.json->companyName. That should match both statements more or less. Unique for user per all developer's apps and cannot be used to track users across *developers*.
But to make it really identical across devices we need to use same hash function. Or - again fetch this token from some other - yet unknown - API.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I suspect it should be fetched from somewhere, and that way it will be consistent with other platforms. I'll ask Katharine when the opportunity next arises.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

Just found out that the new Pebble 2 watches on the Kickstarter only support Bluetooth LE, so it looks like it won't be possible to use them with the Jolla phone at all. Hopefully Sailfish will support BLE on newer devices and ports at some point though, then we can adapt Rockpool accordingly.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

HW seems to be 4.0, it's just sailfish (mer?) which lacks proper BT stack implementation. So we can follow javispedro's suggestion and bring-our-own-stack - as we did with websockets :)

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

I got the impression from that thread that LE won't work without a 3.5 or newer kernel, which the Jolla phone will never have. Anyway, I'm hoping that the Jolla C, and any subsequent phones, will support it.

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

As I understand from this - you can speak to LE peripheral via gatt client api

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 

While I agree with you, maybe it would be possible to implement it first with a cloud based service and letting the user choose to activate it or not and then when a more elegant solution is found, remove the cloud-based part.

I miss the voice service ;)