A glky input question

I’ve got a graphics window which I temporarily widen to cover the main-window so the player can see the whole map. I’ve set it up so that when they press a key, the fullscreen mode ends and the window shrinks again:

open up the map-window; [open big map window to cover the screen] let k be the key_pressed; [wait for user to press a key] follow the shutting down the map window rules; [temporarily close map window to resize it] now measurement of map-window is 33; [make map window a third of the screen width again] follow the opening up the map window rules. [reopen map window]

While waiting for the keypress, various glk events like clicking buttons on the map and such continue to work as normal, so I sought not to mess with them.

My problem is that if you press pageup or pagedown, or wiggle a mousewheel, these events sneak through to the main-window (technically they’re not really sneaking, but I want to be mean to them). The text display moves in the corresponding direction, and in the case where the map is covering the text screen – which it is – I get glitching text half drawing over the map.

Is there some way I can catch/block these events? I note that pageup and pagedown don’t register normally as keypresses. Which is weird, as I can use a debug routine to collect a key_pressed number for them, but they don’t make Inform think “ok, a key was pressed.”

  • Wade

There is no way to catch or block text scrolling.

In Glk, two windows should never overlap at all. If the interpreter is drawing text over the graphics, that’s an interpreter bug.

It was a trick I saw in one of Erik Temple’s Glimmr demos, but sounds like I need to figure out a not-illegal way to do this. Thanks.

Btw, both Zoom and Gargoyle act the same as far as the glitching, so I don’t know if they’re both missing some legality check, or if it’s simply a kind of exploit that Glimmr has created/found.

  • Wade

From Animated Title Page example: “We don’t want to see the main text window at all until the game proper begins. Strictly speaking, we should probably hack the Inform library to allow for this–but that is not a minor undertaking. Instead, we will simply open the graphics window so that it covers the main text window entirely (note the 100 measurement below–this indicates that the graphics window will be split off from the main window at 100% of the latter’s height). The Glulx Status Window Control extension suppresses the opening of the status window; we will open it later, only after closing the graphics window.”

  • Wade

If the graphics window height at 100%, then the text window height is 0%, and the text should not be visible at all.

I am not too surprised that interpreters handle this badly – it’s a corner case, and I’m not sure that my interpreters handle it well. However, that pretty much leaves you with the choice of (a) ask interpreter authors to fix it (b) do something else © live with it.

Heh, I chose (b). I make the map window 95% instead of 100% and temporarily put it above the text. This leaves a sliver of text window at the bottom (which I actually have yet to see any text in). I can’t see any text scrolling or glitching in this position, so that’s good enough.

  • Wade

Wade, I can’t reproduce the glitch you describe on a Mac in either Gargoyle or Zoom: I have a mousewheel, but scrolling with it doesn’t cause this. I don’t have dedicated pageup and pagedown keys on my laptop, but the standard function + arrow combination doesn’t trigger it either. I have no idea why you would see this when I don’t.

Basically, opening a full-app graphics window is something that needs to be possible. The legal way, as zarf’s post implies, is to close the main window, then reopen it again. But the I7 library makes this very difficult to do–I’ve never been able to figure out a way. Even if it were made easy, doing it the legal way raises a couple of other issues: (1) you need a text window open to take keyboard input, so you’ve got to have some text window open. (2) Closing and reopening the main window means you lose scrollback, which sucks.

Given those problems, the illegal overlapping which both my demos and the GWindows project practice seems like the best and most convenient solution to this problem, and I would again make the pitch for legalizing the overlap of graphics windows. Apart from the glitch that Wade is experiencing (which, again, I have never seen and can’t reproduce), the major desktop interpreters already handle this situation quite well, so this would pretty much be the formalization of a situation that already exists, with perhaps only a couple of bugfixes needed from interpreter authors.


Yeah, I was about to suggest that. (The 95% solution.)

To be clear, if a lot of people are running into this situation, I will be happy to write it up as a problem case and ask interpreter authors to fix it.

(You can test this situation crudely in Quixe by going to eblong.com/zarf/glulx/quixe/quix … est.ulx.js and typing “open grid top proportional 100”. It almost works, but the story window’s “More” prompt appears above the story window’s top margin.)

(Then there’s no way to type anything else, but that’s because windowtext.ulx is poorly written and doesn’t provide an input handler for the new 100% grid window.)

Overlapping windows will not happen, because there is too much extra behavior to specify. If we want to improve the behavior here, it will have to be to say “When the size of a window is 0 or 0%, it should become invisible and not interfere with other windows on the screen.”

Sorry zarf, that is what I meant by “overlapping”–poor choice of words on my part. As I said, though, I think that this is pretty much how the major interpreters (barring Quixe) handle things already–what Wade is seeing is not something I have seen in any of my testing, nor can I reproduce it with my current project.

Wade, I don’t know if this is even possible, but is it perhaps the case that the parent of your graphics window is not the main window? That would explain why it is truly overlapping it, rather than minimizing it to 0%.

Is there any good reason why you can’t request character input from a graphics window? That seems like an arbitrary restriction to me.

I don’t have a good argument for that restriction, no. It hasn’t come up in the past, but I was thinking about this earlier today.

If a zero-size window is “off-screen” in some sense – that is, it has no visible display – then it’s reasonable that it shouldn’t accept any kind of input either. But for this case, that leaves you with a 100%-sized graphics window that can’t accept the keystroke which means “close this window!” That’s certainly awkward. (And of course you can imagine building a keystroke-driven game which only uses graphics.)

If a graphics window has keyboard focus, there’s no sensible place to put a blinking cursor. But so what. Gargoyle doesn’t show a blinking cursor for character input, in any event.

I’m willing to put a change into the spec, if people think it’s worth doing. It would have to be labelled optional, with a gestalt test as usual (so that games can detect old interpreters).

Erik, I checked and the map window is being spawned by the main window. However there is another quirk in my setup which may be the cause, if you’re not seeing the behaviour. My status window is opened “by splitting the root Glk window” (David Kinder’s explanation - and his code for this below:)

Include (- [ InitCustomStatusWindow sty; if (gg_statuswin == 0) { statuswin_cursize = statuswin_size; if ( (+ status window background reversed +) ) { for (sty=0: sty<style_NUMSTYLES: sty++) glk_stylehint_set(wintype_TextGrid, sty, stylehint_ReverseColor, 1); } gg_statuswin = glk_window_open(glk_window_get_root(), statuswin_pos, statuswin_cursize, wintype_TextGrid, GG_STATUSWIN_ROCK); } ]; -)

This was done so that I could spawn a 1 pixel high anchoring window above the main text window but below the status line, and, uh… I’m starting to forget why we did all this :stuck_out_tongue: Okay, the upshot was I could close and reopen the map window, and the map window wouldn’t suddenly usurp the entire height of the screen. It would be coralled by the anchor window. And as a result, the status window would never move or change width as a consequence of the movements of other windows.

  • Wade

Zarf, I think relaxing the restriction like you suggest would be a good move.

I never conceptualise character input as being scoped to a window anyway – I’d prefer it was a global event. But that’d be a considerably bigger change. When we get JS and Glk working together I can arrange my events how I like. :slight_smile:

I’ve seen a few games with a graphical “title screen”, where the author would have found things easier if graphics windows accepted character input. It seems like a sensible addition to me.

I agree that these tweaks (char input in graphics windows, official recognition of 0-size windows in the spec) would be great.

Wade, it could well be that the root-window split is causing unusual behavior, I’ve not done that sort of split so I can’t say for sure… Sorry!


Don’t worry, Erik. Now that I’m using the measurement and positioning tweaks discussed earlier in this thread, I’m avoiding the circumstances leading to the glitching.

  • Wade