Before I go do something stupid (Yes, I’m thinking of drawing a keyboard) - it would be really handy to be able to toggle the keyboard on/off and get input from it.
While we’re at it - bluetooth keyboard support (I think I mentioned the iCade before) would be super-awesome. (The iCade shows up as a bluetooth keyboard)
@nilium, when you use it - I’m not talking about for coding, I’m talking about while running. Can you get keyboard input from the bluetooth in your running app??? and if so, how?
str=text() sounds ok for line-oriented input - but I’m looking for keypress info. up/down/left/right arrow, H for hyperspace kinda fun.
Yeah I believe the idea would be to have a hidden text field that passes keystroke information to Lua callbacks in your code.
function keyboard(key)
Might be the API. Unfortunately I don’t think iOS will let us get up/down/left/right keyboard keys from a textfield. It simply changes the selection, if possible. You would have to use W-A-S-D instead.
This is where I got to before I got distracted a week or so ago… I haven’t implemented touch yet, and I’m not sure how to handle “input”, so to speak - I’m thinking it’ll do a callback when a key is pressed.
It’s both ugly and slow, and some functionality (shift, backspace) is unsupported. I don’t like how I’m doing touch, in that the circles are fine for a letter, but some keys (spacebar!) want a bigger touch surface. Still mulling how to deal with that, open to suggestions, or code pushes.
Heh - you bet. The Spacebar doth vex me - stretching the ellipse just looks wrong. and it still has the issue of detecting touch. Right now, I’m just doing a simple distance (really, distance squared) comparison, but I am thinking in the long run something that does rectangular regions will work better…
Rectangles would make it faster. You could home in on the key directly from the coordinates rather than having to test “is it the Q key?”, “is it the W key?”, … .
If speed weren’t an object, I’d go for hexagons since that’s what the distance function is actually computing.
Incidentally, (I know that I could figure this out from your code, but asking you is quicker) how are you drawing the curved lines in the letters? Are they broken lines, or loads of small circles, or loads of small rectangles, or what?
Hexagons? You lost me there - right now, it’s pure Pythagoras - the circles should be pixel-accurate representations of the touched area. I actually compare distance from touch to circle center squared versus the radius squared to avoid the square root (which used to be expensive - no idea if it’s helping much these days).
The fonts are purely line segments - zoom in far enough, you can see the segmentation. Fortunately, they’re high enough resolution that they look pretty good at normal sizes.
I actually believe long-run I’m going to do both circles and rectangles, so I can do things like elongated keys (spacebar) - it’d be 2 circular hit areas, and the rectangle between them. If I do it right, it should be quite fast - because I know the keys don’t overlap, I can short-circuit the search once I get a hit, and I can sort the search by frequency of use (Space, then EATOINSHRDLU…) so e, for example, would be the 4th check (space rectangle, left circle, right circle, then the ‘e’ circle).
I’m not sure any of this optimization is necessary, to be frank - it’s only 50ish keys. The lag in checking them is dwarfed, by orders of magnitude I’m sure, by the delays built into the touch interface.
If instead of “Is it within distance r of key X?” you ask “Which key is it closest to?” then the “domain of attraction” of each key is (roughly) a hexagon.