Most recent activity
-
Hello, just wanted to throw in my 2 cents as a B1 and B2 owner:
- As for the screen, I would love it to be bigger and/or have more colors, but retain the always-on aspect, since I think it's one of the biggest things the B2 improves on. I think the TK78G's screen is perfect, but I personally don't know how feasible would it be to have more colors, bigger screen and an always-on display.
- I'd prefer if the watch would have multiple (at least two, again, like the TK78G) buttons, though I wouldn't be too upset if there was only like one button, but I think it's important to retain the touchscreen - menus are kinda painful with the B1.
- I'm not much of a water guy, so the watch being waterproof is not really important to me, but I think a better IP level would be more beneficial than something like a barometer.
- A better vibration motor or maybe even a speaker would be really cool, but it's not a necessity, in my opinion.
- My B2's HRM was broken out of the box, but if the B1's is anything to go by, it's fine as is, and I think it should stay.
- I don't know if it's a thing smartwatches are "allowed" to have, but having multiple Bluetooth connections would be really sweet, since Espruino is all about hacking, so having to disconnect from my smartphone to use the IDE is a bit annoying. (I assume this is a hardware thing)
- Built-in Wi-Fi would be epic but mostly unnecessary.
- As for the screen, I would love it to be bigger and/or have more colors, but retain the always-on aspect, since I think it's one of the biggest things the B2 improves on. I think the TK78G's screen is perfect, but I personally don't know how feasible would it be to have more colors, bigger screen and an always-on display.
-
One thing I like about smartphones is that they can remember the last state of previously opened apps for some time, which is handy for stuff like games and deep-nested setting menus.
I'm not sure how/if this is implemented on other smartwatches, but I think it could be beneficial to the BangleJS 2.
I think it could be done by just writing vardumps to Flash memory and just loading them when requested? BangleJS 2 doesn't really have free buttons or button combinations, so I'm not sure how state management (quick app open or state deletion) could be done without using up widget space, but maybe a widget button (kinda like the message widget) would be fine.
I figure if such a thing were to be implemented there would beBangle.onevents for before saving and after restoring. -
I'm worried that using a normal JS library would cause memory problems - in some other posts, it can be seen that the Bangle.js 1 is struggling with memory in some posts in some cases. I think I have to agree with Gordon that the upper limit for UIs on the Bangle.js is not that high to warrant very complex UI frameworks.
The reason I originally steered away from a master function is because unlike React, where there's one master function for everything (React.createElement, orjsxin newer versions) and having it always loaded everywhere is consented, a lot of Espruino apps might never want Layout (or not have it at all), so I don't think the React way of making elements is suitable for Espruino.
The way I did it in the intepreter (and what I think should be done) is without a constructor function: the JSX syntax would be a shorthand function call, basically. Esprima natively supports JSX and is used in EspruinoTools, so it would probably make sense to have it convert<Button col="blue">Maybe</Button>to
Button({ children: "Maybe", col: "blue" }), though I could see why part-improvised syntax and grammar might be frowned upon.
-
JSX is usually transpiled by the TypeScript compiler or Babel.
There are multiple issues with my current implementation, I wanted to have a prototype in case it was a definite no.
A thing React does for some reason is when there's only one child, it's not wrapped in an array in the props. My implementation doesn't do this, because it's weird. I don't think it would make sense to implement it because it would require most things to manually wrap the lone child in case it's a child layouting thing (strings are automatically concatenated). I bring this up because TypeScript's JSX support is very flexible, and it almost support using JSX for layout exactly the way I described, except for that quirk.
The issue other than RegEx lexing is the fact that the tag contents (inbetween and ) doesn't allow any characters other than the latin alphabet, this is more tricky than it sounds, as there's no way to tell if a string has had single or double quotes after it has been lexed, and it would require manually adding the delimiter characters, which is not ideal. I think the solution would be to have the lexer have flags for a couple of modes:- Normal - the usual lexing mode
- No tokens - always gives one character at a time, without trying to read strings and stuff. Pretokenised characters might be a problem, but they can just be converted into their string forms (It doesn't matter that pretokenised characters represent multiple characters, since it's going to be appended to a buffer string in any case)
- No regex - this is hacky and less subtle than I personally like, but I don't know of any other way for resolving the issue.
As per having a string and parsing it, there are multiple pitfalls, some of them which are described in the original JSX spec:
- There's no way to verify that the XML is correct before running the code.
- There's no meaningful way of referencing anything which doesn't serialize to a string, eg. there's no way to set a button's callback.
I see why people would be confused as to why JSX is used in a different way versus React, but using Layout requires reading the docs (or examples) beforehand, so if the usecase of JSX can be explained there, I don't think it will be a problem.
- Normal - the usual lexing mode
-
The problem you are facing is that you are uploading your code to RAM and not somewhere to flash storage, which means all the code is stored in RAM as a string, which takes up a lot of space, considering the font. You can see the difference yourself by logging the memory used at the beginning of the file and saving to file vs. RAM (using
console.log(process.memory())).I suspect the non-Layout version didn't run out of memory with the code in RAM because while Layout is great, it does use a lot of RAM to compute the (initial?) sizes of everything.
-
I like the Bangle.js Layout library, and I like React. Both are similar, in my opinion. One thing React has which Layout doesn't is JSX: Instead of having to write object literals or function calls, it can be something which looks like HTML or XML.
For example:const layoutObj = <Vertical> <Label font="20%">JSX</Label> <Button col="blue">Maybe</Label> </Vertical>;instead of
const layout = { type: "v", c:[ { type: "txt", font: "20%", label: "JSX"}, { type: "btn", color: "blue", label:"maybe"} ]}I think it would be cool if the Espruino interpreter supported some form of JSX, since it would make Bangle.js Layout code be easier to read.
I've made a local branch which implements JSX in the interpreter.
I think there can be a problem with JsHint not supporting it and stuff, but maybe it can remedied by updating CodeMirror to use ESLint?
So I've been trying to do a firmware thing for this, where certain Espruino builds would automatically save and load vardumps made with
jsfSaveToFlash(I intend on making a format with a timestamp and maybe a dump of the current Graphics state?) onloadcalls, but I can't seem to figure it out - I save the vardump and load it with the samejs*SoftKillandjs*SoftInitthings as the realsaveandloaddo, but it doesn't seem to load the variables, and instead just run an empty instance, as if there was no loading done at all.@Gordon Can you help me figure out what's wrong, and maybe tell me if something with a concept like this would be merged?
Source code: https://github.com/TheGLander/Espruino/tree/suspend-runtime