maemo.org - Talk

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)

abranson 2016-03-19 18:01

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by Astaoth (Post 1501682)
Ok, so here is the logs when I start rockpoold from the command line : pastebin.com/p4brZPED .
If we take a look at the end, we can read that the new version is detected, but the internal status about available update is set to false. And with the calls from qdbus, I have the same results than before.
Maybe because my version number has an unexpected format rockpool can't define if my version is the latest or not ?

Thanks for that. I think Michael only anticipated that vX.Y.X format, probably because everyone was stopped on 3.9.1. I'll fix that tonight for you.

Edit: version 0.5-2 should be able to cope with you now.

Feathers McGraw 2016-03-19 21:01

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Code:

nemo ~ $ qdbus org.rockwork /org/rockwork/B0_B4_48_C6_10_B1 org.rockwork.Pebble.PerformFirmwareUpgrade
Now running firmware version 3.10.1 on my Pebble Time Steel. Thank you :)

ruff 2016-03-20 10:53

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by Fuzzillogic (Post 1501681)
It's elegant, but will it be enough?

Daemons are controlled by systemd or by user. Even when it is dbus unit it's still called and spawned via systemd. So either you start it in cli manually or via systemd.
Conflict statement allows isolation of the services to avoid "strange unpredictable" behaviour.
Pebbled app allows start/stopping the service and see its status. rockpoold is autostarted by app, moreover app locks down when daemon is not running (falls to waiting for service page).
This basically grants certain predictability, not providing ultimate solution. Bcz ultimate solution should be a user's choice, nor programmer's.

To be completely on the safe side we might implement checks for the stray pebbled processes (eg service is down but process is running) but that's too much overhead and unless reported with certain persistence by users - should be avoided.

abranson 2016-03-20 11:02

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by ruff (Post 1501741)
Daemons are controlled by systemd or by user. Even when it is dbus unit it's still called and spawned via systemd. So either you start it in cli manually or via systemd.
Conflict statement allows isolation of the services to avoid "strange unpredictable" behaviour.
Pebbled app allows start/stopping the service and see its status. rockpoold is autostarted by app, moreover app locks down when daemon is not running (falls to waiting for service page).
This basically grants certain predictability, not providing ultimate solution. Bcz ultimate solution should be a user's choice, nor programmer's.

To be completely on the safe side we might implement checks for the stray pebbled processes (eg service is down but process is running) but that's too much overhead and unless reported with certain persistence by users - should be avoided.

I'd rather not have explicit references to other applications in the code, but we're not fixed to the RockWork design. A lot of that comes from workarounds for the Ubuntu platform. What would you think about having the same service control in Rockpool as Pebbled? I'd already partially migrated the ServiceControl over. It would be easy to add methods to enable or disable the service.

Tbh I'm coming round to the idea of declaring a conflict with pebbled in the RPM. I don't think smokku would mind really.

Btw I added a gitter chatroom. I thought it might be a good place to discuss finer implementation details in realer time.

https://gitter.im/abranson/rockpool

ruff 2016-03-20 11:19

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by abranson (Post 1501743)
What would you think about having the same service control in Rockpool as Pebbled? I'd already partially migrated the ServiceControl over. It would be easy to add methods to enable or disable the service.

Yes, I'm also leaning to this idea, hardcoded autostart is also a bit impolite. RPM conflict is probably way too much, F.i. I'd prefer having both apps on my jolla. Just in case ;)
Service conflict should fine. We may probably also add simple org.pebbled introspection to give a warning when target is published. A fairly simple call to implement in servicecontrol. May even do it right in QML - nemomobile dbus plugin by default is on board.
Chat is a good idea, will most probably need it while merging.

Astaoth 2016-03-20 14:13

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by abranson (Post 1501698)
Thanks for that. I think Michael only anticipated that vX.Y.X format, probably because everyone was stopped on 3.9.1. I'll fix that tonight for you.

Edit: version 0.5-2 should be able to cope with you now.

Thank you, it's working now. :)

I have a feature to suggest, if you have enough time. Do you think it will be possible to use the PT microphone during a phone call, and to have the call sound from the phone speaker ? It could be usefull when driving for example.

abranson 2016-03-20 14:42

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by Astaoth (Post 1501758)
Thank you, it's working now. :)

I have a feature to suggest, if you have enough time. Do you think it will be possible to use the PT microphone during a phone call, and to have the call sound from the phone speaker ? It could be usefull when driving for example.

Are you apps working too?

I know there's an microphone elements to the API, but I thought it was for voice commands instead of Blake's 7 style communications. I don't have a Pebble Time though, so I have no idea. I should think the Voice stuff will be on our shared roadmap with RockWork, but that's a way off yet I should think.

ruff 2016-03-20 20:06

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Ok, so with latest commit interface is somewhat usable.
I didn't touch yet DeveloperPage part (includes screenshot page), firmware update and side-load (import page). The rest is more or less usable. (Finally I've set my fav. apps from jolla :) )

I've noticed that rockpoold segfaults occasionally on reconnection (need to enable coredumps to debug)
Code:

[D] Pebble::onPebbleDisconnected:494 - Pebble disconnected: "Pebble Time C229"
[D] WatchConnection::scheduleReconnect:38 - Attempting to reconnect in 10 seconds
Segmentation fault

Another observation is that app_icon is mostly generic. I.e. I'm receiving mail notifications however icon is still generic. probably because the source is still system event hub, will need to monitor dbus attributes and probably perform certain remapping.

abranson 2016-03-20 21:01

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by ruff (Post 1501773)
Ok, so with latest commit interface is somewhat usable.
I didn't touch yet DeveloperPage part (includes screenshot page), firmware update and side-load (import page). The rest is more or less usable. (Finally I've set my fav. apps from jolla :) )

Brilliant, that's a great start! Let's get it out there!

Quote:

Originally Posted by ruff (Post 1501773)
I've noticed that rockpoold segfaults occasionally on reconnection (need to enable coredumps to debug)
Code:

[D] Pebble::onPebbleDisconnected:494 - Pebble disconnected: "Pebble Time C229"
[D] WatchConnection::scheduleReconnect:38 - Attempting to reconnect in 10 seconds
Segmentation fault


Thanks, I'll keep an eye out. Stability is next priority I think.

Quote:

Originally Posted by ruff (Post 1501773)
Another observation is that app_icon is mostly generic. I.e. I'm receiving mail notifications however icon is still generic. probably because the source is still system event hub, will need to monitor dbus attributes and probably perform certain remapping.

I'm not sure what you mean here, do you mean the icons on the notifications on watch? The current mapping of notifications to pebble icons is in SailfishPlatform:: onNotification. That chooses an icon based on notification owner, category, android package etc.

ruff 2016-03-20 22:03

Re: [Announce] Rockpool - Pebble daemon for Sailfish
 
Quote:

Originally Posted by abranson (Post 1501775)
I'm not sure what you mean here, do you mean the icons on the notifications on watch? The current mapping of notifications to pebble icons is in SailfishPlatform:: onNotification. That chooses an icon based on notification owner, category, android package etc.

No, I mean icons which are used for notifications filter, presumably they should represent local apps which are emitting notifications. So far I see 3 in the filter, gmail, email and twitter, but all of them are having dialog-question-symbolic icon.


All times are GMT. The time now is 13:33.

vBulletin® Version 3.8.8