Gadgetbridge: Html configuration pages of pebble apps

Created on 11 Mar 2016  Â·  48Comments  Â·  Source: Freeyourgadget/Gadgetbridge

Tracking the issues left over from the merged pull request:

  • [x] ~Style the local webpage.~ we let clay do this
  • [x] Properly warn the user if we fail to support an app configuration for some reason.
  • [x] Don't show the configuration menu item for apps that cannot be configured.
  • [x] Consider / add support for https://github.com/pebble/clay/
  • [x] Add support for dynamic keys, as long as they are numeric as per documentation
  • [x] Add a workaround for configuration pages that do not support return_to parameter
  • [x] Allow to store the incoming settings for later reuse (1 slot only).
  • [x] Remember the incoming settings in the db for watchfaces that do not use pebble internal storage.
device pebble enhancement help wanted

Most helpful comment

0.10.2 is available on f-droid and includes all the improvements described lately in this thread

All 48 comments

Clay support is already working through either ashimokawa-playground or danielegobbetti-playground branch. The difference is that the former adds global pebblejs:// support while the latter is more limited in scope.

Adding pebblejs:// support means we can support more watchapps configuration websites (like battery+, that does not support the return_to parameter), but has a few drawbacks:

  • gadgetbridge would also appear as an option in the pebble app when returning from a configuration page
  • the pebblejs:// URL contains no information about the watchapp, only the configuration parameters. This works well as long as one cannot configure more than one watchapp at a time, but we cannot guarantee that. (e.g. user launches the configuration of the watchapp in the official app, and chooses gadgetbridge to open the pebblejs:// URL, but we have no idea which watchapp is being configured).

Either way, clay is a step in the right direction and has to be supported IMO.

just keeping the thread updated.

  • master is now working correctly with clay.
  • external website that do not support return_to parameter are unsupported.
  • a tiny bit of style has been added to the webview
  • we now intercept js errors and show a toast, we will need to show something more meaningful though.
  • apps that cannot be configured don't show the "configure" menu item.

Could someone suggest which watchapp this works and how it works? With the watchapps that I'm using i can't find any way to configure them.
I'm using a Pebble Classic with the firmware 2.9.1.

You have to enable the dangerous/experimental options, then you should see a "configure" menu entry when long-pressing an app in the watchapp list.

I enabled the experimental options and in effect I also see the apps Sports and Golf but when I long-press an app in the watchapp list I only have the voice to uninstall the watchapp, could this depend from my installed watchapps and watchfaces? Or can this depend from the pebble firmware(2.9.1 in my case)?
My only installed watchface is Studio Clock and my installed watchapps are Gentle Wake, Multi Timer and Misfit.

You are right, watchface configuration does not work for fw 2.x because the pbw files won't be copied to the pbw-cache IIRC.

The cached pbws are necessary to allow configuration.

I will fix that after the reconnect bug

If you build master you can test.
Then you will have to reinstall watchfaces you want to configure and long press the first entry of that watchface (there will be duplicates)

Sure, I'll test the next weekend when I'll be back at home where I have my desktop to build the master.

Hey everyone. Just tried it with my watchface. It seems way too paranoid: "Discarded key 2147483635, not found in the local configuration"? With no button to override? That was very unexpected. My watchface adds new keys dynamically. The official Pebble app doesn't restrict keys to only the ones present in the config!

(The watchface doesn't fully work anyway yet... Seems like the JS isn't running when it needs to... or it doesn't have network access)

@myfreeweb I'll test as soon as possible and get back to you. It's good to see further watchfaces/watchapps released under free software licenses (well, public domain in your case) and we do our best to support them.

About the missing keys, the main issue is that we don't know how to cast the values: we could just pass them as strings instead of filtering them out. Can you please confirm if this is what the official pebble app does?
About the configuration page: if it's a local page (read: clay or similar) then it's run within GadgetBridge and it doesn't have network access. If it's an URL then it's opened in a browser. I can try to add an option to open local watchface configuration page in a browser, but that's easier said than done, as the browser would need to open a local file and JS execution may be blocked...

Thanks for your report! I'll look into this issue and report any update/finding.

No, "the JS" is not the configuration page! I'm talking about the JS that runs in the Pebble app in the background! Are all JS APIs implemented? Does it have network access?

I don't know what the official app does re: keys, but it works :)

So, apparently, the documentation says:

The watchapp side uses exclusively integer keys, whereas the JavaScript side may use the same integers or named string keys declared in the 'PebbleKit JS Message Keys' section of 'Settings'. Any string key not declared beforehand will not be transmitted to/from Pebble.

I guess that means if a key is not present in the config, but it can be parsed as an integer, it is sent as an integer...

Interestingly, I have declared some keys like "1": 1 for sequential data a long time ago when creating the first version. When I added settings functionality, I completely forgot that string keys existed, forgot about the config and just defined stuff like #define KEY_VIBRATE_MINUTES INT_MAX-1. Now I realize that's ridiculous and I should've read the docs — but it works with the official app! So it should work with Gadgetbridge as well :)

OK the sting keys part is now clear to me, and is something we can fix.

About running js at runtime it's not something we currently support, but I may look into it and see how difficult it is.

About network access, gadgetbridge doesn't use the network and doesn't have the associated system permission, this is done on purpose and I don't think that will change in the near future. There are other issues where the creation of an external app with internet access is discussed. As soon as that gets implemented, we could try to satisfy your watchapp's use case.

@ashimokawa Yesterday I installed the new update, now i will reinstall my watchafaces and watchapp to test everything and I'll report my feedback with fw 2.x.

I just tested this feature with the fw 2.x and this is wonderful, I noticed only a problem that i think is related at issue #309:
when I try to install a watchface or watchapp for fw 3.x on my fw 2.x obviously the installation fails and I don't have the app on my watch but I have its entry in installed app in GadgetBridge(because in cache I suppose) and I have to remove it manually.

May I ask what's the current state concerning the pebblejs:// URL schema? Whenever a new version of GB comes out I try to configure LGSWatch. I get the configuration page fine – but when I want to submit changes, the browser fails due to "unknown protocol".

@IzzySoft we tell the configuration pages not to use pebblejs:// but since it was introduced in the pebble documentation only lately there are some configuration pages that do not know how to deal with this instruction.
Unfortunately we cannot intercept the pebblejs:// URL schema for two reason:

  • we would bug users that have the original pebble app installed
  • we cannot use the pebblejs:// return value anyway because we don't know to which app the returned data should be sent.

I am currently implementing a solution for this issue, but it requires a bit of user intervention, namely that the user does a copy-and-paste of the "failed" URL from the browser back to the first screen of gadgetbridge app configuration (to a newly added element).

I know it's not ideal but I can't think of other ways to have all the information we need.

@danielegobbetti first item can be voided by making that an option which by default is off, and on being switched on pops up a confirmation box with a corresponding warning. The second I can understand, and would suggest an approach "hidden" behind the "untested features" (or being included with the previous item's warning): provided GB is the Highlander (ahem, the only one, and no "official Pebble app" being used), set a "token/semaphore" whenever a config page was opened (another "Highlander", as opening the page of a second app would move that "token" there). That way it should be clear where the data should go. If a user ignores the warning, GB is not to be blamed for that :)

Unfortunately if we were to support pebblejs:// schema, we would need to add it to the manifest, so it can't be toggled at runtime.
Further, the real fix that I forgot to mention would be to contact the app author and tell them to add support for the return_to parameter, directions are given on the official pebble developers wesbsite so it's not like a random request by some alien :)

Last, there could be another easier option (easier for the user) I.e. adding a toggle on the configuration page "open in compatibility mode" or something among these lines, that points the browser to a page (that doesn't exist yet) that wraps the original configuration page and intercepts the events adding support for return_to. The problem with this solution is that this page would in fact be a man in the middle (all the code would be on the client side, but still you trust a third party) and I don't like this.

So we have a frictionless approach with privacy implications (the one depicted above) and a more complicated one without (copy and pasting the resulting URL).

@danielegobbetti understood – thanks for the explanation, and I'm with you in your conclusion! I'd like to take that road, but in my current example, LGSWatch neither has its issues activated nor seems to be actively maintained (last change was 2014). No idea what would be needed that I could make those changes myself (after cloning the repo) and compile the .pbw file. Would be a bit overkill to install the Pebble SDK for that :) If OTOH it's that webpage one had to modify, I couldn't even access its code …

@danielegobbetti

Another option, based on some assumptions:

  • the watch-app expects some "array/object" of data "posted back" which, if we knew type and content, GB could directly "post" itself
  • GB can detect whether an app has a configuration page

The latter one I'm sure is met, as GB already displays a "Configure" item in the app's context menu if (and only if) such a page exists for the app – "untested features" enabled, that is. The former I'm confident to be possible. So here's what _could_ be done:

  • if a config page is detected, display another context-menu item (e.g. "Customize")
  • this menu item would open a new activity _within GB_, which initially just holds a "+" button
  • pressing the "+" button would open a popup to add a new key/type pair
  • as soon as a key/type pair is present, display it (name and input-field – the latter depending on the type, e.g. text input, check box, whatever) and, next to it, an "edit" and "delete" icon

Now the user just would need to setup that configuration page only once (based on the "original configuration page"), and GB would then save that along the app meta data (cache). The user also can modify it anytime (e.g. if the watchapp got updated and the configuration page changed). Of course this would be gone when the app is removed from cache.

As the current "configuration" item, this should first be part of "untested features". I'd volunteer for testing (with LGSWatch and some other watch-apps if you can name them).

Current master addresses this issue with an input where the user can paste the URL that gives error in the browser.

I tried to make it as little intrusive as possible: this input field isn't displayed before the webpage is opened and is hidden as soon as valid data are returned, so many users will not get confused by it. (That's what I hope at least)

Your idea is the idea we were exploring before finding the browser approach. You are right that there are a few key-values pairs sent by gadgetbridge to the watch, but these can be dynamically generated by the configuration page and may be long and difficult to enter right (0-O, 1-l, etc.)

I tested current master with the watchface you mentioned and was able to configure it by pasting the error URL, so I believe this is an acceptable first solution.

@danielegobbetti definitely! Being able to configure them at all is better then not to :) I was just brain-storming whether there might be a user-friendly and secure way where we do not constantly need to consult external resources. Once set up, my approach would even work inside a bunker covered by 2m lead walls (i.e. no network connection at all) ;)

@IzzySoft you are right, but I hope clay will cover your use case. :)

With the latest improvements I believe the work for this issue is done. I'm marking it as "enhanchement" and "help needed" if someone is willing to step up and style the configuration page differently (It's HTML and CSS).

@danielegobbetti

I hope clay will cover your use case.

Looking forward to that!

if someone is willing to step up and style the configuration page differently (It's HTML and CSS).

I might take a look at that as soon as it's there; in the browser it looks "functional" (but hey, we don't need fancy stuff just to show off :). First look just revelead a minor typo:

In case of "network error" after saving settings in the wathchapp,

WhatApp? ;) And other than the first and last div, the middle one has no header (h2). Maybe something like "Error occured?" (I guess this div is only shown if there was some error). And maybe, to match other screens:

h2 {
  color:#ffffff;
  background-color:#fc5103;
  font-family: sans-serif;
}

Not sure about the latter until I see it on the device, though :)

Clay works already, you just have to "find" a watchapp using it. Hop-picker is an example.
Typo is fixed in current master, thanks!

The middle div is something I don't want to highlight that much, hence I'm not sure if a h2 would fit. About the style, let's wait for the next release so that you can see it in action.

Well, Hop-picker looks a bit confusing to me. But I'll figure if I happen upon such an app then :)

And of course fully agreed to "wait and see" the page in action before daring to say what should be changed :)

0.10.2 is available on f-droid and includes all the improvements described lately in this thread

@danielegobbetti thanks! Noticed the tag yesterday. My F-Droid client is just updating its repos, I will update GB ASAP and check :) _BUZZ!!_ Ah, there it comes … Yeah, works! :+1:

I just wanted to change the date format in LGSWatch. Stupidly, that replaces the week number but leaves the date sticking on "Jun 20th" instead of doing it the other way around. Well, not the fault of GB :)

Just an idea (nice-to-have): Especially for those apps where the "normal config page" fails and one has to copy-paste the URL, would it be possible to add "favorites/profiles"? Think the following workflow:

  • config page opened, some settings adjusted, button pressed
  • failure notice (pebblejs://) pops up
  • copying the URL, closing the web page manually
  • back in GB, paste the URL and press the "Parse" button
  • additionally to the "send to Pebble" button, get the option to "Save as profile for this app", pressing that, being asked for a name, the combo gets added as e.g. another button (which still is there when the menu is opened again)

Next time:

  • config page opened
  • profile button pressed, done.

This is especially useful if one only "switches" between different settings but does that frequently. And is somehow something in between what we have now and what I've suggested here ;)

Yes, I like this idea. I believe that it would fit well as an additional requirement for the db we are discussing in #206. Currently the db focus the activity storage, but application data may/should end up there as well.

@IzzySoft

(using GB v0.10.2 on 'Pebble Time Steel' (PTS) (with os v3.13))

very good suggestion, as i have a problem with one of my watch faces, in that -

the "normal config page" fails as its a pebblejs:// link etc and one then copy-paste the new config-URL,
back in GB and press the "Parse" button and the watchface is changed okay on the PTS but if i then go to another watchface on the pebble and come back to that particular watchface, all the new config is gone.

So yes, your suggestion -

_"additionally to the "send to Pebble" button, get the option to "Save as profile for this app", pressing that, being asked for a name, the combo gets added as e.g. another button (which still is there when the menu is opened again)"_

is a very good one :)

(Not that this solves your issue, but) many watchfaces actually store their settings on the watch, so far I haven't encountered one that doesn't, to tell the truth. It is possible that js based watchfaces are different, though. But I wouldn't expect a js watchface to use ancient configuration pages, so I'm puzzled. Can you share which watchfaces has this issue? I'd like to understand what's going on.

Anyway, I agree that this is a good idea and it will be added.

@danielegobbetti

thanks for all the good work as without GB i wld not have bought a pebble because of the obvious privacy issues :)

yeah possible the problem is to do with how this particular watchface stores its configuration file, as i've configured other watchfaces via GB that have kept their new configuration but those were not js based watchfaces though.

anyway, here you go - this is the watchface in question -

https://apps.getpebble.com/en_US/application/56bacc111e72001aee000042?dev_settings=true&section=watchfaces

@john453 Glad that you like my idea. And:

without GB i wld not have bought a pebble because of the obvious privacy issues

The very same is true for me. And to give credit: I might not have found GB if not Pebble staff itself had pointed me to it. But the GB team itself has really convinced me, standing behind their app (and have the privacy concerns in focus), having a very active project, magnificient support, being very communicative, plus being really great to work with!

@danielegobbetti

Anyway, I agree that this is a good idea and it will be added.

:+1: Yeah! :smiley_cat:

@IzzySoft

indeed to all you said about the GB team and kodus to them too for a great app :clap:
...and good on the pebble staff to point you in GB's direction, i saw it at F-Droid :smile:

with 'pebble time 2' later on in the yr with the bigger screen GB will be most handy and gain more popularity!

Thanks a lot for the kind words :-)

I found the sources of the watch face:
https://github.com/mereed/pebbleface-fullscreen3
​
It seems to me it's relying on javascript local storage instead of the watch internal memory. We don't support this (as we don't support js runtime, actually). It may happen sometime in the future but we have to figure out the best way to do it first.

Thanks for the nice words.
I also bought a pebble because there was Gadgetbridge as an idea in my head ;)

with 'pebble time 2' later on in the yr with the bigger screen GB will be most handy and gain more popularity!

The new Pebbles won't work with Gadgetbride out of the box. It will take some time to support them. Actually this is not easy because Pebble switched to Bluetooth LE, which is a completely new way of communitcation with the Pebble. Don't expect anything usable from us in 2016 even though it is high priority once the watches are out. I might also put a big read warning on in the README, so that no one buys a 2016 Pebble expecting it to "just work"

Next release will include a quick and dirty solution to store a single incoming configuration as "preset". In the future we might implement multiple presets.

@danielegobbetti c00l! Yeah, 2 or more presets are quite useful if one often needs to switch. One is already very useful for those watchfaces forgetting their configuration ;)

Some day ago I saw that I can also configure Misfit but when I try to do this I have the error: "Uncaught TypeError: Cannot read property "ready" of undefined".
What this means? Can we really configure Misfit?

@tecufanujacu Wouldn't that be a separate issue? This one explicitly is about Pebble apps :)

@tecufanujacu:
No right now configuration of Misfit is not supported.
What would you like to configure?
Since we have native support for Misfit we could also honor the sleep goal settings and maybe covert step goals to Misfit points (~ steps/10).

@IzzySoft
No, Misfit IS a Pebble App. The only good option for OG Pebbles IMO.

@ashimokawa Ouch, of course. I just saw the first two letters (Mi*) it seems :see_no_evil: Sorry for confusion!

@ashimokawa
Oh yes, I'd like have the possibility to set the goal for sleep and for steps.

as far as i understood this issue i should get an error message in the browser where i can copy the content to GB. There are some nice watchfaces that use the pebblejs return but they dont result in an error on my nexus5 stock firmware with current chrome. One example is http://expando.github.io/misc/pebsaltv.html a face to test would be https://apps.getpebble.com/en_US/application/5551c4a91113bc93a00000de?section=watchfaces .
I assume this is a chrome problem which probably cant be fixed. Would it make sense to spawn webview in GB instead of operning the URL in the OS default browser?

Since a few months pebble released clay: a js framework that works completely offline. This is supported within GB (without invoking an external browser).
GB cannot view internet-hosted configuration pages as it doesn't have access to the internet. This is not going to change.
We do our best to interact with the system in the most clean and standard way, but it's not entirely under our control.
You may try one of other web browsers available for android, if you want to see if it helps. Firefox works well for me.

ok thanks. I will try firfox and also mail the developer if he can is willing to change to clay.
Thanks for your work.

Finally closing this, as I believe we are almost feature complete.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Jiack214 picture Jiack214  Â·  4Comments

ruimnetob picture ruimnetob  Â·  4Comments

ShapeShifter499 picture ShapeShifter499  Â·  3Comments

ghost picture ghost  Â·  7Comments

RustyRaptor picture RustyRaptor  Â·  3Comments