Search results for:

@fparri keep in mind that (as I wrote in the readme) the app is mostly a proof of concept for now, as you noticed sync works, but code generation is done on the device and not in the best way.
Complex QR codes give a hard time to the device and it reboots (didn't try with complex barcodes but those would likely not render fine).
As many said, the best thing would be to have the codes generated by the phone (Catima perhaps), but that is not how the gadgetbridge integration currently works.
Any help is more than welcome, at the moment I don't have much time to work on that (and I don't have much knowledge of android and barcode/QR generation to make the algorithms smarter)

@Akisame the cards app is roughly a proof of concept. It works fine with gadgetbridge (catima sync) but the rendering of codes is way far from being perfect. I tried some open source libraries but feel free to fork/enhance the app with your own renderers.

Right, good point.
Just out of curiosity, is BW clock really working so different or could it eventually use addInteractive too?
If that's the case I'd wait for them to be unified before checking this update on the agenda clkinfo.

Thanks, I guess I'm starting to grasp it better!
I think at this point a couple of other clkinfo would need an update then:

• the agenda should drop passed events as they are over
  
• the weather should trigger an update once the old data is expired and when up to date data is available
  
• I think the alarms are fine, since once one fires the screen is changing and going back to the clock would refresh anyway (does it always happen?)
  
  

Does it make sense?

So now the right way to handle the show for items that are always ready is to do nothing at all?
Are we both drawing manually (also the non-ready ones) and redrawing once data is ready/changing?
I see that the function menuShowItem is indeed triggering a redraw after calling the show, isn't it the same old story then? (Well I assume the idea is to keep it more under control)

By the way, I'm not quite sure I fully understand the use of show (as it is right now).
Clocks are supposed to call show, most of the times emitting a redraw, which eventually clocks are handling (on) while drawing. Isn't this equivalent to just calling a redraw on the first place (assuming no one else emits another redraw, which is the case for some clkinfos, like calendar date and battery).

If I understood correctly, the simple this.emit("redraw"); lets the clock decide when to update (in a convoluted but standard way), while other ways can force redrawing on some events or timers. Am I missing something?

In the reference Implementations I have always seen something like this.emit("redraw"); as only content of the show.
You are right as probably yours wouldn't really change, but emitting a redraw won't hurt (say one day you want to show something else, it shouldn't be called that often anyway).

Good to know, looks promising!

Well, thanks, I'll keep the tape then! Don't want to mess up with the watch

Well, didn't mean to criticize your method (very neat, by the way). Just the clkinfo (and modules in general) are quite hard to track as they aren't versioned, so I first thought it could be that.
If it's about pretokenisation, I should see it soon, perhaps it gets triggered with some state of the weather file, which I didn't get yet. Let's see.

Do you mean the problem is there just on 1 bangle out of 2?
It could be anything, different versions of the clkinfo module (which gets pulled on install), some outdated file/app roaming around for whatever reason, or anything else.
A better error log could help narrow it down.
Anyway I have pretokenised all of my apps and have no errors, so reinstalling might have fixed.

I couldn't reproduce the error with clkinfos on my setup, however I found that the code printing that warning isn't exactly helping out with the problem..
Could you trigger the exception while adding something like

console.log(e);

in the same catch box where that is printed (should be clock_info:133).
After that, the result might tell something more meaningful.
(For simplicity I can try to set up a branch with that modification on my fork, stay tuned)

EDIT
Here you go, by uninstalling and reinstalling the offending clock (slopeclockpp) with my app loader's fork (https://glemco.github.io/BangleApps/) you should be able to use this modified version of the clock_info module. You can check the only new commit in my master branch is adding that line.

.

Any news on this? I once had the crazy idea of wanting Opentasks tasks on the bangle without the need of modifying open tasks at all. Didn't dig into it too much for lack of knowledge on the android layer, but my idea was to use the share button which would produce a text, send it to gadgetbridge as a FW/App (the menu is there but I'm not sure it works, it didn't when I tried) and maybe have it ask what name should the file have on the bangle.
Not a real synchronization but quick and easy for the use case in which you want to put something once on your bangle from any app (a shopping list or a train ticket from catima), which could be displayed and managed by a companion app on the watch itself.
Do you think this can be useful? How much of this can already work/can be done with low effort?

Hello all, my tape got out too (and it has been moving for a while), I was considering some more permanent solution like instant glue on the two pins.
Do you think something can go wrong with this? I guess I should be able to remove it with something like WD-40 in the worst case. Any recommendations? I don't have any nail polish at hand.