Cannot scroll buffer after glk_exit

[GoogleCodeExporter]

Scrolling is sent as character input to the game, meaning that for something 
like Czech, it exits immediately. For the Z-Machine this should never happen. 
Potentially for Glk/Glulx it could, but we'd need to update the standard to add 
the scroll wheel as special characters. For now they shouldn't for Glk either.

Original issue reported on code.google.com by curiousdannii on 8 Feb 2012 at 3:04

[GoogleCodeExporter]

Scroll wheel activity gets transformed into a PageUp / PageDown key. Are those 
not legal Z-Machine keys? They are valid Glk keys, and I like the behavior in 
general.

Czech is not exiting because a key was sent to the interpreter. It's already 
terminated when the screen appears, because glk_exit has been called. That 
parks the library in a loop that closes the window on the next keypress.

It should be possible to scroll the window event after glk_exit, but fixing 
this is rather tedious and I've been putting it off.

Original comment by bcressey@gmail.com on 8 Feb 2012 at 6:17

• Changed title: Cannot scroll buffer after glk_exit
• Changed state: Accepted

[GoogleCodeExporter]

As it turns out they aren't valid Z-Machine keys, but the VM should take
care of that (and turn them into ?'s)

I'm less comfortable with the idea of converting them into page up/down.
They really do quite different things. My thinking is that for interpreters
with real scrollback, the VM should never know when you're scrolling
through the scrollback. But that's just me, I haven't heard anyone else say
anything either way. Have you checked with Zarf what he thinks about
converting the scroll wheel to page up/down? For all I know he might be
planning to support it directly.

On Wednesday, 8 February 2012, wrote:

Original comment by curiousdannii on 8 Feb 2012 at 8:22

[GoogleCodeExporter]

This is really annoying. Many games will clear the screen for any key press. 
I'll be scrolling down, but if I scroll one too many times, BAM! cleared screen 
before I finished reading it. See To Hell in a Hamper for an example. One 
mildly overzealous scroll and you've missed three pages of text.

We shouldn't have to precisely control how many times we're scrolling, which if 
you're using a touchpad rather than a mouse will probably be close to 
impossible considering there's no physical feedback.

Original comment by curiousdannii on 23 Apr 2012 at 2:50

[GoogleCodeExporter]

Can you try the attached patch?

- The window can now be scrolled after glk_exit is called. Mouse scrolling 
should never trigger an exit; keyboard scrolling will but only if the MORE 
prompt is not displayed.

- Mouse scroll events are no longer passed to the interpreter. I think this 
feels a bit weird but I agree that certain games (To Hell in a Hamper) are 
nearly intolerable otherwise.

Original comment by bcressey@gmail.com on 25 Apr 2012 at 11:11

Attachments:

• fix_scroll_behavior.patch

[GoogleCodeExporter]

This issue was closed by revision r598.

Original comment by bcressey@gmail.com on 4 May 2012 at 8:18

• Changed state: Fixed