This is GlkOte (part of Quixe). I just tried to fix the bug that made it impossible to enter commands on some iPhones and Android browsers. (The Enter key just didn’t work.)
There are plenty of problems left, I know. You’ll have to tap on the (nearly invisible) input form field to bring up the screen keyboard, and you’ll have to do it again after every command. But it should be possible to enter commands.
It works on iPhone 4 but annoyingly it zooms in when entering a command, and you have to manually zoom out again after pressing Return to read the output.
It doesn’t seem to be possible to scroll back? And longer pieces of output (such as typing help in landscape mode) scrolls past without a more prompt.
The top windows are too small for their content. Both status window and quotation box only show a small part of the second line.
After a while, the input line drops down, out of view, and becomes unuseable. Sometimes. It happened on my first try, but I can’t seem to reproduce it. (A while later: ) Now I reproduced it. Turns out that happens if I turn the device. Apparently the changing height / width confuses it. (Update again: ) That’s not the whole story. Now it happened to me again without me having turned it. I don’t know why, but there was some scrolling involved (because I have to zoom in to read the text).
The “map” isn’t aligned. (It’s not displaying fixed-width.)
Slow didn’t take long. About a second. (Don’t know if that’s an issue or not.)
Other than that, it seems to work ok. (I tried everything listed by help.)
layout works well in both horizontal and vertical mode as long as it is display-only
enter key on soft keyboard works
the input field sometimes disappears until I click on it, but most of the time it is displayed after a turn
when in input mode (vertical), the soft keyboard covers up the input field, but will appear as soon as you enter input, in horizontal mode, the input field just takes up all available space, so the output is invisible.
I will adjust the viewport eventually – I’ve done it for Parchment sites, I just need to transfer the knowledge over. And I’ll adjust the fixed-width font.
I don’t know how I’m going to deal with scrolling and paging. Ensuring that the window scrolls to the bottom on resize (device-rotate) will patch a few of the problems. But I don’t know if it’s possible to give an HTML div (as opposed to the whole document) the standard touchscreen drag-scroll behavior.
Input focus is biting my unmentionables. The ideal is: tap on a window to focus the input field (and open the screen keyboard, if the platform has one). But Safari makes this very difficult. But not impossible. It works right now (iPhone/iPad) if you tap on a different window and then tap on the window that’s expecting input. But if you tap the window where you just entered a command, nothing happens. There is some magic going on with default event handlers, and I really wish I understood it.
I’ve updated the viewport and made the display non-zoomable.
The not-exactly-monospace font turns out to just be the way iPhones are. Blah!
I’m still thinking about resizing and scrolling. But, bonus feature discovery! You can scroll a part-visible div using a two-finger drag gesture. So you can work your way to the bottom of a misaligned buffer window, albeit not comfortably.
I’m not so sure about the non-zoomable thing. It means a lot of scrolling back and forth since the window is wider than the screen, regardless of the orientation of the screen. If it matched the screen in wide mode, I think I’d be happy with it. Now it’s too narrow in both modes to be pleasant to use, and IMO too big in wide. It doesn’t have to be readable from the other side of the room.
Best would of course be if it worked like Frotz and always adapted the width to the actual width of the screen (while keeping the size of the letters the same), but I don’t know if that’s possible in a browser?
Windows seem to be the right size, except immediately after turning the device. It fixes itself when a command is entered.
Hm. I tested it on iPhone (original) and iPad, plus the simulators, and it was always the right window size. Maybe your browser had some size information cached? I’ve seen that happen in iOS Safari.
Yep, that fixed the width. (And changed the colours.) Height of status window is still wrong when turning until a new command is entered, but the way it is now, there seems to be no reason for turning it to widescreen anymore. It appears to be in a state where it could be used to play a game now.
