Notices

So I managed to build the websockets lib myself and verify that it installs correctly from my repo when given as a dependency, and I can start it. So upgrading to it should be no problem for anyone when the dev connection's ready!

Great! So do I understand it right that it solves warehouse installation/upgrade path? So the dependency will be picked up and pulled automatically?

For DevConnection I've added pin-ops handlers (which are not doing anything except dumping the pin into logs - requires proper timeline implementation) and PhoneLog - with phone log we can now collect daemon logs using pebble sdk command (pebble logs --phone jolla).
I'm not committing it yet because I found some race conditions due to the fact that service is enabled in dbus thread and running in app thread - so it segfaults under certain conditions. need to wire up all calls properly via queued connect and probably put some mutexes for syncbox calls.

Yes precisely. We can consider websockets to be available. I purposely built the latest stable version, a bit older than coderus' version, so that if Jolla include it themselves, then it'll supercede mine.

I've uploaded 0.10-1 with the notification changes and the JS websockets. This should pull in my builds of QtWebSockets, so please let me know if you have any problems.

EDIT: Also, I'll wipe out your existing notification filters sorry, I had to change the format and the key.

Awesome! The new update shows the (newer) notifications from Skype too now! Thanks for this!

btw regarding app upgrade - I've implemented missing piece for upgrade in the daemon (together with devcon app install). That involves change of the local path where side-loaded apps are installed. That means that if you have any side-loaded apps - remove them prior to upgrade, or there will be a mess.

I'm also leaning towards changing local path for appstore-apps from storeid to uuid. That will allow manual upgrade (downgrade) for appstore apps using sideload/pebble-sdk option. That implies however that users must remove all apps prior to such update (loosing all the settings).

Possible way around that would be to create a transitional wrapper which will be checking both - store-id and uuid paths and push the app to the existing container. later we may remove it after several releases.

anyway atm going to add appstore-app-upgrade feature. but since i don't have any candidate for upgrade installed it will be rather theoretical exercise

Edit: thinking abt it a bit i came to the conclusion that I'll simply modify the installer code to rename the dir on the fly to uuid (if it's not already) once an overwrite (existing app) happens. During install apps are rescanned anyway so daemon should pick up changes, while watches care only about uuid anyway.

fyi I have updated to 0.10-1 and I have noticed that it is not possible to filter some notifications: at least for notifications from the app 'situations', I have received several of them on the watch but I cannot see any entries in the notifications part of rockpool. And it was possible previously.

I put that list up because there wasn't a list of unimplemented features and I thought I'd spare people asking for them. I didn't expect those things to be in progress already. You're on fire, dude

Agree with UUID instead of Appstore id. Pebbled stored the pbws by UUID, so I'm not sure why he changed it.

Looks like the situations notification are quite non-standard - no owner is set. I'll work around that, because those are quite annoying.

Is there a way to disable "ephemeral" notifications (or at least have them go away from the watch)? Like, when you connect or disconnect a TOHKBD it creates one of the drop-down notifications at the top of the screen - it doesn't ever show up in SFOS's notifications window, but it sits there on the pebble (and can only be dismissed by the back button, because when you try to "dismiss" it says "Failed", probably as a result of the notification not being on the phone.)