[glk, I7] the whole enchilada

Aaaaahhh, I’m getting it. Increment by hard-won increment, I am getting it.

Your redraw code doesn’t work in WinGlulxe (edit: or Gargoyle) (haven’t tested it on anything else). It compiles, but the figure doesn’t redraw when you resize the window. Other than that, everything is running smooth.

Ah, quite right. Windows skips the redraw event if there’s a window-resize event, because it’s redundant.

The fix should be one additional rule:

Glulx input handling rule for an arrange-event when the illustration window is open:
	let F be the illustration-name corresponding to a link-number of current illustration link-number in the Table of Illustrations;
	redraw the full illustration of F;

This doesn’t work in Gargoyle, and I’m not sure why. Sorry.

As promised, here’s the code ported to Unified Glulx Input:

gist.github.com/erkyrath/1386e832eab296798be8

The big change is that opening and closing the illustration window are now actions. The hyperlink/mouse/char events are understood as these special actions. This is easier to understand than your original code, because we’re not doing all the fancy work inside the parser’s input-handling rules. It’s just the familiar I7 model: an input generates an action, and then you handle the action.

Note that there are no I6 calls to request or cancel keyboard input. UGI handles all of that. There’s still one call to glk_request_mouse_event for the illustration window. (UGI currently only manages the main window, so we have to cover that one.)

The “display thumb” call is simplified because we have I7 shortcuts for making hyperlinks.

There’s also no need to say “redraw the status line” except when a window-resize event arrives.

The window-arrange event now works correctly in Gargoyle (and, I expect, in WinGlulxe as well). I think the Glulx Entry Points extension was somehow dropping the event in its resize-debouncing code. Or I don’t understand how that code works. Anyhow, the UGI version does the right thing.

Very cool.

I still use “clear the screen” in a few non-illustration-displaying contexts as well, though. If I copy that code over from Basic Screen Effects:

To clear the/-- screen: (- VM_ClearScreen(0); -).
will that cause problems with UGI?

(I tested it and it compiles, but since you mention that the extensions are not compatible, I want to make sure I’m not causing some undetected but horrific side effect by including it.)

No, that’s fine. It’s the various “wait for a key” calls that have seriously changed under the hood.