swipe keyboard code crash on back button

I'm noticed a problem with the swipe keyboard.
Here's how to reproduce.

1. create a new note ysing notify
   
2. edit the note
   
3. tap the screen to display the screen of swipe singles
   
4. press the physical button to go back.
   
   

the result if connected through the IDE is

         |_| espruino.com
 2v13.13 (c) 2021 G.Williams
Uncaught Error: clearInterval(undefined) not allowed. Use clearInterval() instead.
 at line 3 col 1881 in textinput
...clearInterval(flashInterval);Bangle.s­etUI();g.clearRect(Bang...
                              ^
in function "back" called from line 1 col 8
b.back()
       ^
in function called from system
>

Also I was wondering if the symbol screen could be black on white or white on black.
I'm struggling to see the symbols in red on black/white.

NOTE looks quite clear in a screenshot - but a lot harder to see on the watch.

1 Attachment

I don't even see the back button

1 Attachment

You may not see the red button unless you have upgraded to the 2v13 firmware and are using the new menu system.

This issue is more around using the hardware button which also does a BACK action.

Just fixed this.

In terms of the swipe patterns - I guess maybe when you're pressing it could be different? PRs welcome ;)

I just didn't want something that would stop you reading the text you had written if it was drawn...

In a way what's needed is a just much bigger picture in the README itself though - which I just added :)

Updated to 0.04. The back button issue is fixed.
I'm a familiar with the old Graffiti gestures, had a few Palm OS devices in the early 2000s.
There a lot of potential with this, its much easier to use than the Touch Keyboard.

I'm getting a few issues getting the following letters to be recognised:

• w more often than not coming out as space
  
• I cant get q at all
  
• z more often than not comes out as a y
  
• g can be tricky. The only reliable way for me is to put a loop in it - like the picture below.
  

1 Attachment

w more often than not coming out as space

And you're definitely on 2v13 firmware? I had to make some changes to improve things - but I found that as long as you do use as much of the full height of the display as you can it was ok?

I think one big issue is that the letters shown are what I recorded in basically one try with my finger on the watch so are a bit wonky. Ideally we need either to actually make the letters programmatically (maybe put them in an SVG and then try and export the strokes with https://developer.mozilla.org/en-US/docs­/Web/API/SVGGeometryElement/getPointAtLe­ngth), or by aggregating the strokes produced by a bunch of different people.

Personally I don't have the time to get stuck in to that minefield. PRs welcome though ;)

For instance if you record your 'q' and replace it in the keyboard code and it works better, maybe contribute it back?

And you're definitely on 2v13 firmware?

Yes on 2v13.13

as long as you do use as much of the full height of the display as you can it was ok?

The problems with w,q,y,z are all after I descovered that using the full screen was the best strategy.

For instance if you record your 'q' and replace it in the keyboard code and it works better, maybe >contribute it back?

Took me a while to figure out how to do that but the comment in lib.js helped.

/* To make your own strokes, type:

Bangle.on('stroke',print)

on the left of the IDE, then do a stroke and copy out the Uint8Array line
*/
exports.getStrokes = function(cb) {

So I did successfully manage to record a few of my q's. I was attempting to use the old PalmOs Q as much as possible. But I found just looking at the code that is printed that there can be a lot variable between one stroke and another.

I tried the code and it did improve this and I got q's reliably BUT the printed graphic was not a good exmaple of what I feel I am tracing out, so I have not committed as think overall it makes things worse.

1 Attachment

I had to keep commiting, pushing to my Loader as I could not remember how to make a change to a lib.js and get it sent via the IDE to textinput. I tried loading it into the left hand side of the IDE but I get an error on trying to upload to textinput. A problem wth export.xxx etc.

Changed lib.js to use g.theme.fg instead of RED and feel it is easier to read.
Will do a PR.

Definitely endless amounts of fiddling to be done with this.

Original cribsheet below with g.theme.fg as foreground.

1 Attachment

how to make a change to a lib.js and get it sent via the IDE to textinput. I tried loading it into the left hand side of the IDE but I get an error on trying to upload to textinput. A problem wth export.xxx etc.

I've noticed this problem/bug with the IDE as well. When I have the code written on the right hand side and choose to upload to the textinput-file i get the same kind of error message as you. However, I've found that the textinput-file actually do get updated with my code anyway, just reload by holding the side button as usual and test the keyboard again.

So the error message feels redundant?

how to make a change to a lib.js and get it sent via the IDE to textinput.

You can write direct to the textinput file but then you'll have to explicitly load(..) your text input app all the time.

Or... I just put exports={} up the top, then some test code down the bottom like exports.input({text:"Foo"}).then(result => { console.log("Text input", E.toJS(result)); }); and upload to RAM.

Changed lib.js to use g.theme.fg instead of RED and feel it is easier to read.
Will do a PR.

Yes but doesn't the text you're supposed to be writing end up written over the top of the in the FG color, like in the picture you posted in http://forum.espruino.com/comments/16494­559/ ? That makes things look very broken to me.

However, I've found that the textinput-file actually do get updated with my code anyway, just reload by holding the side button as usual and test the keyboard again. So the error message feels redundant?

You have Load after saving set as the default of Load the file just written in the IDE - so Espruino is trying to load the library you just wrote as if it's an app - which is why there's the error.

It could of course try and guess whether you're writing a widget, boot code, library etc based on the filename but that feels like a minefield

Ah, ok! Thanks!

That makes things look very broken to me.

The cribsheet display is model - IE only displays when you tap the screen.
The letters type so far are not shown until you do another letter gesture
at which point the screen returns to showing the letters.

It is fairly hard to read in RED but easier in fg/bg.
As the letter font is quite bold, it does not feel broken.

2 Attachments

When I run this code:

Bangle.loadWidgets();
Bangle.drawWidgets();
require("textinput").input({text:"Foo"})­.then(result => {
  console.log("Text input", E.toJS(result));
});

Right at the start I see the attached. Do you not see that too? It seems from your first post that you do.

1 Attachment

Just tested your code. Exactly as I said:

Personally that looks broken to me. I don't know, maybe make it draw it first in color and then when you tap make it draw in black and white?

1 Attachment

Yes I do see that - but its only when you first open an existing note to edit it.

I think there is a case for not showing the cribsheet when you go to edit a note. If you are editing it is safe to assume you know you can tap the screen to get the cribsheet if you want it. Not sure if that is possible with the code. I guess the cribsheet would initially only be shown if length(notetext) == 0 OR you tap the screen ?

maybe make it draw it first in color and then when you tap make it draw in black and white?

That works.

I think there is a case for not showing the cribsheet when you go to edit a note

Yes, absolutely. Only thing I'd say is it's then not obvious that you're actually in a position where you're expected to edit text... so I guess we should have some prompt like 'swipe to input text'