Flexible Windows - Incorporate Text Window Input-Output Control

[curiousdannii]

There are a few places where the templates run glk_set_window(gg_mainwin);:

1. VM_MainWindow()
2. Box__Routine()
3. FileIO_Close()

I think that we should probably patch these to instead refer to the current g-window. It's too much to expect authors to do this themselves, and if they don't use the variable the behaviour will be as it is now. If they are using the variable, I can't think of any reason why they wouldn't want it to be patched.

In 4dd07fa I began patching it with an after constructing the status line rule and with changes to VM_KeyChar() (which I left commented out). If we do what I suggest above then I don't think the status line rule will be required. The change to VM_KeyChar() won't actually change where stuff is printed, and Text Window Input-Output Control could be used for that if needed.

[ektemple]

Hm, how will this interact with Text Window Input-Output Control, which also hacks those three routines (i.e., VM_MainWindow(), Box__Routine(), and FileIO_Close())?

[curiousdannii]

I'll have to give it a more detailed look, but I think incorporating part or all of TWIOC into FW is the way to go.

[curiousdannii]

The 'set focus' phrase could be used to update TWOIC's variables. Two APIs for one underlying I6 system. I think it will work.

Why doesn't FW give direct access to the status window like it does the main window?

[ektemple]

Sounds good.

I don't think there is really a good reason for FW not to give direct access over the status window; my guess is that Jon didn't want to generalize the sorts of routines that control the status window display to other grid windows. I am very happy to see my specific-function extensions like TWIOC and Status Window Control disappear and their core functionality find a home in FW.

(Note that Status Window Control's is not the right approach--expanding the FW interface is definitely the way to go.)

[curiousdannii]

@ektemple, I've done a basic incorporation of TWIOC into FW. The focus phrase now sets all three window variables, though I feel like "the current g-window" and "the current text output window" are essentially the same.

I couldn't include TWIOC's version of "return to the main window" because with the focus phrase setting "the current text output window" it didn't do anything.

Printing the status window puts the focus in the wrong place I think. I'm going to try letting the status window be directly accessed, so we could fix that when I've done so.

Any thoughts?

[ektemple]

It sounds like you have redefined the current text output window to mean the same thing as the current g-window, but they actually aren't intended to be the same. The current g-window always refers to the window that has Flexible Windows focus; I don't think it's really likely to be used very often. The current text output window is to be set you want to use another window as your game's replacement for the main-window. In other words, the current text output window is persistent and shouldn't be changed automatically--returning focus from an ancillary window should always return it to the current text output window. (In the overwhelming majority of cases, authors will of course leave it set to the default, i.e. the main-window.)

Probably the name of the current text output window should be changed to something like "main text output window" so that this distinction will be more clear.

[curiousdannii]

Thanks Erik. Hmm, I think I see where I had misunderstood before. I'll see if I can fix it.

Would it be appropriate for my Menus extension to open its pop over window as the main output window? Is that the kind of intended use?

Do you need to worry about the window for character input? (As an author I mean, the extension should do everything properly.)

[curiousdannii]

Should the prompt related rules finish by focusing the output window, or should they save and refocus the current g-window? I think the second one is better, and not hard to do.

Unless I've missed something, TWIOC doesn't actually hack FileIO_Close??

[ektemple]

Glad to see that you're humming along with this!

Would it be appropriate for my Menus extension to open its pop over window as the main output window? Is that the kind of intended use?

Yes, that's the sort of thing it's intended for. It's not really useful in that situation unless you also have ancillary windows--but you just might have them! Other use cases include: using a grid window as your default output stream, needing to be able to open and close your main window to change window styles, etc. (A better solution for the latter would be to allow the main window itself to be opened and closed, but I've never been able to figure out how to make that work with the I7 library.)

Do you need to worry about the window for character input? (As an author I mean, the extension should do everything properly.)

Practically speaking, no--all of the major interpreters accept character input even from 0-height windows. But it's probably best practice to switch the target of character input when, for example, you use a popover window. (Not possible yet if your only visible window is a graphics window, but if I recall zarf is changing the spec to allow graphic windows to accept character input.) For the new FW, I think it might make sense to have character input default to the current text input window.

Should the prompt related rules finish by focusing the output window, or should they save and refocus the current g-window? I think the second one is better, and not hard to do.

In practice, I think that this would have little effect except when the author has forgotten to use the "return to main window" phrase. Even then, the bug should be just as easy to identify as with the TWIOC behavior. So, sure!

[curiousdannii]

Any thoughts about what should be changed in your new version 10 of Glulx Entry Points? I noticed lots of uses of gg_mainwin there. Should GEP be modified at all, or should all the changes happen in FW?

[ektemple]

Actually, for the most part GEP doesn't have to care about windows. I see just two references to gg_mainwin, both in phrases that provide alternates to FW phrasing, since we can't assume that GEP users are also using FW:

To cancel line input in the/-- main window:
        (- glk_cancel_line_event(gg_mainwin, GLK_NULL); -)

To cancel character input in the/-- main window:
        (- glk_cancel_char_event(gg_mainwin); -)

Again, this is why I think there should be a centrally blessed effort to provide a unified, extensible framework for Glulx at the I7 library level...

[curiousdannii]

Oh, I thought there were more but maybe I just remembered wrong. Those two should be easy to fix. I wish inclusions were more consistent so that we could just override the phrases.

[curiousdannii]

@ektemple could you please open a new issue for the ability to open/close the main window, with the relevant use cases for that?

[curiousdannii]

I've had an idea, but it has potential downsides. If we update gg_mainwin to be the ref-number of the current text output window then a lot of the template replacements wouldn't be required. The downside would be that a phrase would be required to change the current text output window - if you changed the variable directly gg_mainwin would be out of sync. We would need extra phrases for switching the main window to one which is already open. What do you think?

If we took the approach of phrases the current text output/input window could be hidden and renamed, which would be clearer for those reading the extension's code. (And if they're hidden then authors would be discouraged from changing them that way.)

[EmacsUser]

I'll admit that I haven't been following this discussion closely, but, depending on how you feel about Evil Beguilement of the Source Text Parser, you might consider intercepting now-based writes:

Section "Demo"

A foo is a kind of value; the foos are bar and baz.

Quux is a foo that varies; the quux variable translates into I6 as "quux".
Include (-
    Global previous_quux;
    Global quux;
-) before "Definitions.i6t".

To detect a change to quux (this is detecting a change to quux):
    say "(Quux changed to [quux]!)".

To --/-- now (A - a foo variable) is/are (B - a foo): (-
    previous_quux = quux;
    {A} = {B};
    if (previous_quux ~= quux) ((+ detecting a change to quux +)-->1)();
-).

Section "Test Case"

There is a room.

Plugh is a foo that varies.
When play begins:
    now quux is bar;
    now plugh is baz;
    now quux is plugh;
    now plugh is quux.

[curiousdannii]

You are far too clever. I guess it would be even more straightforward to intercept changes to specific variables. The ones in question are I7 variables, not I6 ones, so a simple "To --/-- now the/-- current text output window is (win - a g-window):" should work I think.

[curiousdannii]

This is finished now that I've rewritten it.