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)

I like the idea of having some sort of

str = text()

command which brings up the keyboard and lets you type something in. Will have to talk to Simeon about it.

I am fairly certain Simeon added bluetooth keyboard support for the editor already. We have talked about iCade support and will consider it.

When we eventually open source the backend, we could get help from the community for API ideas!

I currently use Codify/ea with a Bluetooth keyboard, so it definitely works.

@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.

Hmm… iSSH supports arrow keys, so it’s gotta be possible.

Not that it matters for the icade - that’s all regular letters.

Does iSSH support it for something other than moving a caret around text? I’ll look into it some more.

it doesn’t appear to be a regular text dialog (not that there are many of those on the ipad).

I’ll bet notepad does as well (my bluetooth keyboard is at work or I’d try it myself now…)

After looking at it some more, it might be possible.

iCade support would be awesome, is that a possibility?

Yes we’ve discussed that and are looking into it, along with the Joypad app for iPhone.

I blame Apple for making me start a keyboard class.

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.

Ok - added the touch code and some keypad stuff, and a sample “display” function.


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.

Haha nice!

Trying to embed it (not sure if Twitter will let me). Edit: I’m guessing this is related to the rounded rects question?

Custom Keyboard

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.