Most recent activity
-
I'll admit that this threw me off a bit too at first.
It does appear that there is some inconsistency in the standard app UIs as to what Back does, which is unfortunate since it probably makes things more confusing than they could be. For instance, in the Alarms app, going to the menu to create a new alarm or timer, then immediately tapping Back without making changes, immediately creates a new alarm or timer with default settings, which isn't really what I personally would expect to happen. I'd expect the operation to be canceled, or perhaps a prompt asking whether I meant to save the new item. But then in most other places, Back actually does cancel the changes rather than confirming them. It's not really obvious which “rule” is in effect on a particular menu.
In the case of the number-changer screen, perhaps having an OK button on Bangle 2 to set the value would be a bit more intuitive, assuming there is space for it.
-
Thanks! That seems to work. Darn, I had a back-of-the-mind thought about trying the offline compiler but really didn't expect it to change anything. Looks like I was wrong.
Should we update
dane_arwes.jsas well? I'm not sure what uses that, but its correspondingdane_arwes.min.jsalso appears to have a mismatched commit/timestamp. This looks like the only other minified file inmodules/that I can see. -
I'm having some confusion regarding the Layout library: I suspect the version of the code in the current emulator and my Bangle.js device does not match what I see in
masteron GitHub, and I'm not clear on how versioning works. The docs seem to say that the current version of modules are supposed to be automatically loaded from the app loader, but I seem to still have a version of Layout.js that is almost a year old despite having used my fork of the development app loader definitely much more recently than this.Then I happened to notice in the BangleApps repo that there is a Layout.js and a Layout.min.js file, and the latter is several months older than the former, the former containing the functionality I was looking for but in fact I'm guessing the older minified version is in fact the version that is actually getting deployed. I can confirm this by manually installing the non-minified version into the IDE emulator under a different name (different because apparently if I use “Layout” the built-in version still takes precedence), and I see that the specific behavior of the newer code then works.
Assuming someone simply forgot to update the minified files when making changes, I was going to use EspruinoDocs/bin/minify.js to update the minified modules and PR the update, but I can't get the minifier to work for Layout.js (though I've successfully used it for other files). I get errors I don't really understand; I guess the script doesn't understand the result from the Closure compiler. I've attached the full output log of the minify script.
If anyone could shed some light on how this works or let me know if I'm barking up the wrong tree somewhere that would be great.
-
That's odd - how exactly were you listing files?
I was seeing the duplication both in the app loader's app list and when browsing the Storage files in the IDE.
I can't be exactly sure when I first noticed it, but it was pretty soon after unboxing. I think the very first thing I did upon plugging it in to charge and powering up was to update the firmware (since the app loader suggested it). I think the old FW was 2v16 or 2v17, can't remember for sure, and I installed 2v18. I think I tried installing apps directly after that.
Anyway, I noticed that the duplicate files did not appear in the ZIP produced by the backup feature, so I tried what you said and made a backup and restored it, erasing storage before the restore. Everything seems intact but with only one “sched” app instead of two, so it seems that solved it.
-
The codes in the debug log definitely look like terminal escapes, though I'm not sure exactly what formatting they're for. Normally colors and formatting aren't that essential, but perhaps other characters in certain output might be important. If it is just the same output that the left pane in the IDE would display, I wonder if it would make sense to have a button or tab shortcut there for viewing the contents of the debug log using the same VT100 interpretation of escape codes. I'm not sure if the debug log file is an Espruino- or just Bangle-specific implementation, but it seems like a quick-view feature could be a handy debug tool.
The BLE interval makes sense. That would also explain why the response in the console sometimes seemed a little laggy for a moment. Checking the running app is a good point; I should have thought of that but didn't. I've mainly been using Timer Clock as the clock, but I just tried it with the default Anton clock and the first page of Settings and didn't notice any difference in behavior—it still happens the same.
I played with setConnectInterval and do notice that any interval higher than about 100ms seems to consistently reproduce the bad behavior. Lower intervals work okay. So far it seems that this is the only thing that causes the weird behavior.
Yes - this is more laziness in implementation I think. The text is added to the filename in the Storage window so you can see that the files are different (as this can be important), but then when saving the original filename should really be used.
Although... I have to juggle a lot of stuff with Espruino - it is literally just me working full time on this - and it's unlikely I'll get time to put in fixes for all this stuff. If you'd be willing to jump in and make some fixes, that'd be great - as with the app loader you can just fork the IDE and host your own copy with GitHub pages for development if that's easier than having a local serverUnderstandable. I'm kind of overwhelmed with various ideas myself and it's hard to decide what to do when. :) It looks like the priorities are in the right places, though, as the important underlying functionality seems pretty solid. Most of the things I'm encountering are fairly minor UI/polish type stuff, and that can always be fixed. I may consider taking a stab at some of it at some point.
I estimate that I'm typically getting up to around 2 weeks regularly wearing the watch with:
which seems pretty reasonable. In practice since I use the watch as a daily driver I normally charge a bit more often than that to avoid the battery dying at a bad moment. Since the battery meter tends to hang out around 9–10% for a long time it's hard to be sure what the true max runtime would be without risking that; I consider that level as a sort of “charge as soon as possible” low-battery signal.
I do notice that long use of timers that update in 0.1-second intervals tend to drain the battery particularly rapidly. (At least one app seems to do such updates only when the screen is awake/unlocked and then cuts back to once per second, which seems like a good idea.) But occasional use of once-per-second displays for a few hours here and there doesn't seem to hurt overall runtime too badly.