swipe keyboard code crash on back button #4574
Replies: 1 comment
-
Posted at 2022-04-24 by HughB Also I was wondering if the symbol screen could be black on white or white on black. NOTE looks quite clear in a screenshot - but a lot harder to see on the watch. Attachments: Posted at 2022-04-25 by user140377 I don't even see the back button Attachments: Posted at 2022-04-25 by HughB 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. Posted at 2022-04-25 by @gfwilliams 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 :) Posted at 2022-04-25 by HughB Updated to 0.04. The back button issue is fixed. I'm getting a few issues getting the following letters to be recognised:
Attachments: Posted at 2022-04-26 by @gfwilliams
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/getPointAtLength), 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? Posted at 2022-04-26 by HughB
Yes on 2v13.13
The problems with w,q,y,z are all after I descovered that using the full screen was the best strategy.
Took me a while to figure out how to do that but the comment in lib.js helped.
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. Attachments: Posted at 2022-04-26 by HughB 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 Posted at 2022-04-26 by HughB Changed lib.js to use g.theme.fg instead of RED and feel it is easier to read. Definitely endless amounts of fiddling to be done with this. Original cribsheet below with g.theme.fg as foreground. Attachments: Posted at 2022-04-27 by @thyttan
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? Posted at 2022-04-27 by @gfwilliams
You can write direct to the Or... I just put
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/16494559/ ? That makes things look very broken to me. Posted at 2022-04-27 by @gfwilliams
You have 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 Posted at 2022-04-27 by @thyttan Ah, ok! Thanks! Posted at 2022-04-27 by HughB
The cribsheet display is model - IE only displays when you tap the screen. It is fairly hard to read in RED but easier in fg/bg. Attachments: Posted at 2022-04-28 by @gfwilliams When I run this code:
Right at the start I see the attached. Do you not see that too? It seems from your first post that you do. Attachments: Posted at 2022-04-28 by @gfwilliams 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? Attachments: Posted at 2022-04-28 by HughB 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 ?
That works. Posted at 2022-04-29 by @gfwilliams
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' |
Beta Was this translation helpful? Give feedback.
-
Posted at 2022-04-24 by HughB
I'm noticed a problem with the swipe keyboard.
Here's how to reproduce.
the result if connected through the IDE is
Beta Was this translation helpful? Give feedback.
All reactions