glkote

glkote copied to clipboard

Apropos https://github.com/erkyrath/glkote/issues/48

iOS native IF interpreters (including, at least, Frotz and iosglk) have a feature in common: they have a header bar at the top of the screen with a keyboard button on it. When you click the keyboard button, the keyboard opens; when you click it again, the keyboard dismisses.

That button is especially important on the web, because it's easy to accidentally dismiss the keyboard by tapping anywhere on the screen except on the input line. When you do that, the only way to bring the keyboard back is to guess where the input line is and tap there.

Plus, sometimes you want to dismiss the keyboard (to see more text on the screen), and then easily bring it back again.

I think glkote (or Parchment??) should offer a header bar like this. The bar should include the title of the game and a keyboard button. (And maybe someday it should include text styling options: font, size, light/dark theme, etc.)

Parchment used to make it that if you clicked/tapped in the general page the input box would be focused. Do you think something like this would be a better UI? It makes sense to me.

One difficulty is that it probably would be the responsibility of the framing UI rather than GlkOte directly. But it would then have to go into GlkOte to focus the input box. There's also the issue that Glk games have multiple inputs at once, one per window. Maybe GlkOte could expose a function to return a list of active input boxes, and the UI keyboard button could cycle between them?

Parchment used to make it that if you clicked/tapped in the general page the input box would be focused.

I worry about stepping on other UI events like text selection, scrolling, and context menus.

Maybe GlkOte could expose a function to return a list of active input boxes

That wouldn't be a problem.

I note that you can already get this list by doing the jquery call $('#gameport input'). A function could return more info (window ID and rock), and it would be slightly more future-proof, but for the foreseeable future it would give the same list of elements.

Do we know for sure that focusing the input box will bring up the keyboard? Glkote already has code to call inputel.focus() after every input. It's obviously not sufficient to solve the problem.

.focus() only brings up the keyboard if it's in response to a tap (click), which is why my PR #9 fixes issue #48. (Focusing the element in a setTimeout does give it "focus" in the sense that document.activeElement is the inputel but it doesn't actually bring up the keyboard.)

But I filed this issue #49 above and beyond #48, because if we merged my PR, it would remain easy to dismiss the keyboard and have no user-visible way to get it back. Frotz and iosglk converged on the same solution for this, a keyboard button, and that's why I think Parchment/glkote should have/do something similar.

The "tap-to-type" placeholder is an improvement and is hopefully good enough. I agree that a dedicated keyboard button would be great, but it's hard to fit in when you know nothing about the game layout. (Lower right corner of the screen is least-bad, but it will still obscure something important sometimes.)