maemo.org - Talk
Page 9 of 18 « First 78 9 1011 Last »
Show 40 post(s) from this thread on one page

maemo.org - Talk (https://talk.maemo.org/index.php)
-   Applications (https://talk.maemo.org/forumdisplay.php?f=41)
-   -   [SFOS] [Announce] Rockpool - Pebble daemon for Sailfish (https://talk.maemo.org/showthread.php?t=96490)

ruff 2016-04-17 19:28
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?

abranson 2016-04-17 19:38
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.

Fuzzillogic 2016-04-17 21:06
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by ruff (Post 1503885)
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?
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 :)

abranson 2016-04-17 21:35
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by Fuzzillogic (Post 1503901)
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 :)
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.

ruff 2016-04-17 22:24
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.

abranson 2016-04-17 22:39
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by ruff (Post 1503912)
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.
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.

ruff 2016-04-17 22:54
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.

abranson 2016-04-17 23:09
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.

ruff 2016-04-18 06:30
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by abranson (Post 1503919)
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.
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).

abranson 2016-04-18 08:41
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by ruff (Post 1503925)
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.
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.

Quote:
Originally Posted by ruff (Post 1503925)
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).
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.

abranson 2016-04-18 20:57
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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!

ruff 2016-04-19 10:09
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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.

abranson 2016-04-19 11:58
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by ruff (Post 1503999)
Great! So do I understand it right that it solves warehouse installation/upgrade path? So the dependency will be picked up and pulled automatically?
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.

abranson 2016-04-20 06:37
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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.

HtheB 2016-04-20 09:52
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by abranson (Post 1504051)
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!

ruff 2016-04-21 06:55
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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.

P@t 2016-04-21 07:52
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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.

abranson 2016-04-21 07:53
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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.

abranson 2016-04-21 08:07
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by P@t (Post 1504099)
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.
Looks like the situations notification are quite non-standard - no owner is set. I'll work around that, because those are quite annoying.

taixzo 2016-04-21 14:45
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
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.)

abranson 2016-04-21 15:17
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
I thought they were already hidden - they're called transient notifications. I'll have to attach my tohkbd again and test it.

abranson 2016-04-21 18:19
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by taixzo (Post 1504120)
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.)
I've just tried on my tohkbd, and they get discarded before they get to the filters. Can you check if you have the file /usr/share/lipstick/notificationcategories/x-harbour.tohkbd2.conf? It should contain the line 'transient=true'. If it does, then the output of 'journalctl -laf' as root while connecting the keyboard should tell us more.

taixzo 2016-04-22 16:03
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by abranson (Post 1504137)
I've just tried on my tohkbd, and they get discarded before they get to the filters. Can you check if you have the file /usr/share/lipstick/notificationcategories/x-harbour.tohkbd2.conf? It should contain the line 'transient=true'. If it does, then the output of 'journalctl -laf' as root while connecting the keyboard should tell us more.
I do not have that file.

P@t 2016-04-23 08:51
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
1 Attachment(s)
btw I had some time to run the logs for the problems of Caldav appointments not being sent to the watch.
I can see that the gmail calendar events are indeed being sync , and I do not see problems except maybe at the beginning of the logs even though it is not clear to me which of the error and success wins :) :
Code:
[W] mKCal::ExtendedCalendar::defaultStorage:2057 - Unable to create calendar database directory: "/home/nemo/.local/share/system/privileged/Calendar/mkcal"
[C] {anonymous}::semaphoreError:57 - semaphore_p.cpp: 57 - Unable to get semaphore /home/nemo/.local/share/system/privileged/Calendar/mkcal/db: Invalid argument (22)
[C] ProcessMutex::ProcessMutex:214 - semaphore_p.cpp: 214 - Unable to create semaphore array!
[C] {anonymous}::semaphoreError:57 - semaphore_p.cpp: 57 - Unable to decrement semaphore /home/nemo/.local/share/system/privileged/Calendar/mkcal/db: Success (0)
[C] mKCal::SqliteStorage::open:180 - sqlitestorage.cpp: 180 - cannot lock "/home/nemo/.local/share/system/privileged/Calendar/mkcal/db" error "Success"
[W] OrganizerAdapter::OrganizerAdapter:25 - Cannot open calendar database

abranson 2016-04-23 09:33
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by P@t (Post 1504262)
Code:
[W] mKCal::ExtendedCalendar::defaultStorage:2057 - Unable to create calendar database directory: "/home/nemo/.local/share/system/privileged/Calendar/mkcal"
[C] {anonymous}::semaphoreError:57 - semaphore_p.cpp: 57 - Unable to get semaphore /home/nemo/.local/share/system/privileged/Calendar/mkcal/db: Invalid argument (22)
[C] ProcessMutex::ProcessMutex:214 - semaphore_p.cpp: 214 - Unable to create semaphore array!
[C] {anonymous}::semaphoreError:57 - semaphore_p.cpp: 57 - Unable to decrement semaphore /home/nemo/.local/share/system/privileged/Calendar/mkcal/db: Success (0)
[C] mKCal::SqliteStorage::open:180 - sqlitestorage.cpp: 180 - cannot lock "/home/nemo/.local/share/system/privileged/Calendar/mkcal/db" error "Success"
[W] OrganizerAdapter::OrganizerAdapter:25 - Cannot open calendar database
This output is what you get if the daemon is running without permission to access the calendar database. This can happen either because it was run manually through qtcreator or from the console, or if it hasn't had its permissions added property to the mapplauncherd permissions config.

The best way to get calendar logs out if to relaunch the service with the GUI, while watching the output of 'journalctl -laf' on an ssh session. This will make sure that the service is launched with the proper permissions.

I can see it removing the calendar entries that had been loaded when the service was running though - those 'removing stale entries' lines - but that doesn't say where they were from, or why others were skipped.

ruff 2016-04-23 10:07
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by abranson (Post 1504100)
Pebbled stored the pbws by UUID, so I'm not sure why he changed it.
Seems I've figured why. AppStore accepts only StoreID - it has no knowledge of the UUID (or at least doesn't expose it to API). However StoreID is not part of apps's metadata.
It means it's not stored anywhere. So appdir name was a way to store the StoreID. If we move to uuid - we then need to store it separately. which by itself is not a big deal.
However since I've already added logic to handle existing apps - the easiest and most consistent way would be then to use following logic:
* For app fetched from the app-store - check if app exists, if yes check current appdir matches StoreID, if not rename it to StoreID.
* For sideloaded app - check if app exists, if yes - install to existing appdir, otherwise install under uuid.
That should allow overriding appstore-installed app by sideloading and other way around.

P@t 2016-04-23 12:57
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Thanks @abranson
I am far from being a developer so I may do stupid mistakes :p

See below a link with logs from the journal this time. I do not find any obvious error so my guess is that Caldav entries are just stored in another place which is not read?
http://pastebin.com/7DujHMNz

I have also tried to see what happens when I try (and fail) to sync misfit:
http://pastebin.com/LkxY17Jv

abranson 2016-04-23 17:41
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Yeah all I can see in the first one are successful entries, there's no mention of anything skipped or missed. You could try disabling one of the caldav calendars in the calendar app and seeing if it's mentioned in the log. There is no other place for them to be stored afaik.

I'll have to reinstall my misfit to check that. It seems to be the problem I thought I'd fixed.

junnuvi 2016-04-24 06:43
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Thanks for your work with this great app!

One idea: is there possibility to make phone change profile when silent mode will be enabled from Pebble?

abranson 2016-04-24 13:18
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by junnuvi (Post 1504306)
Thanks for your work with this great app!

One idea: is there possibility to make phone change profile when silent mode will be enabled from Pebble?
I think that might require a watch app - I don't think Rockpool can tell if the watch is in quiet mode or not. If it could, then that's another justification for the JS DBus API to be implemented ;)

Amboss 2016-04-25 08:48
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:
Originally Posted by P@t (Post 1504271)
Thanks @abranson
I am far from being a developer so I may do stupid mistakes :p
Well, making mistakes is the purpose fo testers. And those mistakes are most of the time not stupid... When I test scripts, I usually behave foolish on purpose, this might help errors won't show up when "regular" users do something not thought of before.

ruff 2016-04-26 22:36
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
After implementing app upgrade realized I actually do have one app eligible for update - again the Authenticator :) So the new version devcon4 with upgrade is going to beta, preparing to merge/pr
edit: while implementing gui was doing upgrade and sideloding downgrade multiple times - the app didn't lose the auth tokens so up/down-grade looks smooth

ruff 2016-04-27 06:40
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Oops, jolla removed silica documentation from the sailfishos site... are they deprecating it? any rumours?

Feathers McGraw 2016-04-27 08:39
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
1 Attachment(s)
Uh oh, that doesn't look good at all!

Server out of space - do you think that's bad sysadmin or some kind of DoS attack?

:(

abranson 2016-04-27 08:47
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Maybe it needs a btrfs balance ;)

MikeHG 2016-04-27 11:16
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Android app beta 3.12 is out, featuring among other things offline settings pages for watch apps / faces.

https://www.reddit.com/r/pebble/comm...a_312_release/

Not sure if there's been a corresponding firmware change, but something worth thinking about for the Sailfish (and Ubuntu...) sides too anyway.

ruff 2016-04-27 12:56
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
you dont need anything specific for offline pages, it's just a file:// scheme. there's really no dependency in config pages on being online

abranson 2016-04-27 14:03
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Katharine was talking about this in the telegram chat this morning. Apparently they've just dropped the online-check before opening the settings page, so if your browser supports offline browsing, and the page generates its pebblejs: link itself without submitting to a server, it'll work. Most don't though apparently, but before this the settings would refuse to even try if you were offline.

MikeHG 2016-04-27 14:07
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Excellent. It's always been a bit of a bugbear for me - there are a few apps (like 'Get Back To') for which you often want to use the settings page with a sketchy data connection. I guess now the app developers will have reason to redesign their apps with that in mind.

Another quick query, if you don't mind:

Did you ever get a chance to have a look at Trebble / Checklists for Trello? It now shows "Network failed (0):" here whenever I run it, which is at least a different error. Wondering whether it's something wrong here, or if it's still broken generally...

Thanks again.

ruff 2016-04-27 14:12
Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Ehm, wait but you're just requesting config url from the app, it's up to app what will it give to you - http://configure.myapp.com/pebble.html or file:///tmp/configure.myapp.com-pebble.html - browser will open both url disregarding whether you're online or offline.
Of course two issues here - you need either to prepare that path (eg. copy the config folder with all resources to tmp) or to provide custom schema (eg. pebblejs://open/) which will in our case be mapped to something like .local/share/rockpoold/<mac>/apps/<sid>/config_page


All times are GMT. The time now is 15:51.
Page 9 of 18 « First 78 9 1011 Last »
Show 40 post(s) from this thread on one page

vBulletin® Version 3.8.8