Flexible Windows - allow the main window to be opened and closed at will

[ektemple]

Now that FW can treat any window (or windows) as the main window for purposes of either output or input, it would be good to allow the author total control of the main window (gg_mainwin). Possible use cases include:

• Closing and reopening the main window in order to change text styles. (This is how the glulx version of Photopia was able to change text colors for each chapter, for example.)
• Allowing the author to close the main window when it is not needed rather than making use of the frowned-upon expedient of "popping" another window over it. Examples include graphic intro screens such as Kerkerkruip has. (There are still use cases where the popover window is the best option, however: for example, a popover menu screen allows the main window to retain scrollback.)
• Allowing the author to use window types other than buffer windows as the main I/O interface, i.e. a text grid window or even a graphics window.

[curiousdannii]

Thanks!

Is it necessary to make the main window closeable while others remain open?

Actually, while that would be possible with glk, FW's spawning relation is different - sibling windows become children. So closing the main window will automatically close all the others.

[ektemple]

I don't think it's necessary: if you didn't want the main window's behavior, you could close it and then open something else. But all this means adding another abstraction, e.g. the root window object.

[curiousdannii]

If the properties of the main window can be changed then there shouldn't be any need to have an alternative root object. Or would a root object make graphics windows easier? Are there any technical problems or interpreter inconsistencies with a pop over graphics window? Would you be happy with closing the main window, converting it to graphics, and opening it again?

When I was looking at the code yesterday I couldn't see any reason why the main window shouldn't be closeable - the main issue is that FW doesn't understand the status window, which I'm already going to fix.

[ektemple]

I think being able to convert the main window to some other type and reopen it would probably be fine! (Of course, you should also be able to change the type before opening it if that were allowed.)

(My feeling is that zarf doesn't like popover windows much--see the intfiction discussion awhile back--and I think that the spec if undefined as to what should happen when a window pops over another.)

[erkyrath]

Reducing a window to zero height (which is what we're really talking about) is legal, but interpreters tend to get weird about input and scrolling when you put them into that state. My opinion is to avoid it where possible.

However, there are cases where you can't avoid it. Keeping scrollback is the big one.

[curiousdannii]

This is now fixed!

However Inform doesn't seem to support requesting line input in a text grid window. But that's not a problem for FW to fix.

[ektemple]

Great, congrats!

However, Inform definitely supports line input in a text grid window. The example "Terminal" from TWIOC did just that, and I'm quite certain it worked in both Zoom and Gargoyle at the least. I just tried it compiling against v13/130925 of FW, though, and it no longer works. I'm not sure why, or if FW is at fault, but it isn't a limitation of the I7/I6 library or of the VMs.

[curiousdannii]

Okay, I'll figure it out then. I'm still yet to copy the TWIOC examples into FW, so they'll help me to ensure it gets fixed.