These are chat archives for abranson/rockpool

28th
Mar 2016
Christopher Frost
@cgfrost
Mar 28 2016 09:49 UTC
I really like @Fuzzillogic suggestion but if open access to dbus is a concern then how about a new namespace on jskit that only gives out specific information about the phone. e.g. Sailfish.batteryState or Sailfish.wifiState etc... It wouldn't stop any existing watch apps from working on Jolla and it would be down to the developer to gracefully degrade the functionality of there app if they are running on a platform that doesn't support everything.
Andrew Branson
@abranson
Mar 28 2016 15:33 UTC
There are two possibilities I see here. The first one is very Sailfish - giving an open dbus access to JS apps. This would be quite platform independent in its implementation because it would use the qt dbus stuff, though most the calls probably wouldn't be. I don't think it's a massive security risk though - the daemon doesn't run as root so it won't be able to do anything that any other app could. The upside is that people would be able to do things on their pebble with Sailfish that other platforms would never allow, which I think is one of the strengths of the OS that most people don't realise.
The other would be a new JS API object to expose things like battery and wifi state as you suggest. We could possibly propose this through the telegram channel, as katharine is senior enough at pebble to seriously discuss the possibility. That sort of general phone system info could perhaps be supplied on every platform. That would be very cool.
I don't think they have anything like that yet.
Andrew Branson
@abranson
Mar 28 2016 15:39 UTC
You guys would be very welcome on the RockWork telegram channel btw
Christopher Frost
@cgfrost
Mar 28 2016 19:08 UTC
I think there is a good argument for both. A new JS API for stuff common to all phones, things like battery, wifi state etc.. that should be defined by Pebble. Then also do the dbus access for more general Sailfish access that can make Sailfish stand out. I'm happy to spend some time working on these but I'm not sure how to proceed, any advice? (I'm also only a beginner C coder, if it were all in Java I'd have done in flash :) )
Andrew Branson
@abranson
Mar 28 2016 20:15 UTC
I know the feeling! I've done nothing but Java for the last 15 years before dabbling in pebbled late last year. I vaguely remember about pointers and that, but I'm sure C++ has changed since I learned it back in uni :)
All the JS Kit stuff is in rockworkd/libpebble/jskit - there's not that much of it. There are a few objects defined in there, like the timers, geolocation and xmlhttprequest. Then the jskitsetup.js does some weird function proxying to allow it to be called from the JS engine.
The strangest thing is you've got c++ on one side, super strict compared to Java, then on the other you've got javascript dragging its arse along the ground.
Have you got the Sailfish SDK? That's really easy to get going with.
Christopher Frost
@cgfrost
Mar 28 2016 20:29 UTC
I've learnt C so far by writing a pebble watchface. I did all the Sailfish tutorials before 2.0 came out but never got my head around how the QML code and the C code communicated. I'll go and have a look at the rockworkd stuff and suggest the new JS API and see if katharine is listening. Thanks.
Andrew Branson
@abranson
Mar 28 2016 20:46 UTC
The qml app in rockpool is quite clear for that. You see the C++ objects defined in the main, and they get referenced in the QML.
Have you got the link to the telegram group? Katharine is really helpful, but she's just had some sort of major operation so she's been in and out.
ruff
@rufferson
Mar 28 2016 20:49 UTC
There's still dark magic happening in the QtQuick glueing together qml and qt, but it's more or less logical if you know qt concepts (like properties, signals/slots, etc)
Andrew Branson
@abranson
Mar 28 2016 20:50 UTC
I see eldritch things scrolling past when it builds. If something breaks that starts with moc_ then i just do a clean build and hope it goes away... ;)