Flexible Windows - Beta version 15 for 6L38

I have completed enough of my rewrite of Flexible Windows to satisfy Kerkerkruip. It’s not quite finished, and there’s no documentation, but it’s complete enough to share here now.

Please download it here:
raw.githubusercontent.com/i7/ex … indows.i7x
You’ll need these too:
raw.githubusercontent.com/i7/ex … Points.i7x
raw.githubusercontent.com/i7/ex … 0Rules.i7x

My rewrite has some small changes that weren’t strictly necessary, but which lead to cleaner code in my opinion. A short migration guide for the most common changes you’ll need to make is:

  • Many kinds, properties and the main/status windows have lost their hyphens
  • Colours/styles updated to match GTE
  • The window-drawing rules have been turned into the refreshing activity. It is no longer necessary to focus or clear the window
  • The hyperlink processing rules have been turned into the processing hyperlinks activity.

Depending on how advanced the features you used were, you may need to make further changes to your code. Hopefully the code is easy enough to read and figure out what to do, but if you can’t, please just ask here.

Some things are not implemented yet:

  • bordered windows
  • echo streams
  • input phrases
  • the command prompt activities

This is a big extension, and I’m quite proud of it. :slight_smile: If you’re interested, please take a look at the source code. I hope it might be a useful model both of how to organise large extensions and how to do some tricky things in Inform.

Well done. It’s a very useful extension and was due an update or five.

Thanks! “Include Flexible Windows by Jon Ingold” has been commented out of my current WIP for quite awhile.

I’m running into a quick problem using it, though. I seem to be having a lot of line break trouble. Consider this code:

[code]Include Flexible Windows by Jon Ingold.

Example Location is a room.

The topic-window is a g-window.
The main window spawns the topic-window.
The position of the topic-window is g-placebelow.
The scale method of the topic-window is g-fixed-size.
The measurement of the topic-window is 3.

When play begins:
open up the topic-window.

Every turn:
refresh the topic-window.

Rule for refreshing the topic-window:
say “Turn count: [turn count]”[/code]

For some reason this seems to add a line break into my main window every turn.

I will investigate.

Yay! Thanks Dannii. I’m glad this is still proving useful, even if my work is the archaeopteryx to your, um, chicken.


Jon, haha I hope you can still recognise your work underneath mine!

Floating Info, Sorry for taking so long, but I’ve now uploaded a fix for that bug.

It’s time to turn this beta into a proper release (and get it in the public library etc.) I’m thinking that the complete silence on the absence of the echo streams, input phrases, bordered windows, and command prompt phrases means that no one is missing them. Rather than making Flexible Windows do everything, how about, if someone does need those features again, they go into a separate extension?

Along the same lines, would anyone be greatly inconvenienced if I removed the hyperlinks section that is currently in FW? It’s really completely stand alone, and could easily be made into another extension. I could in fact do that now if anyone needs it, but I suspect that it’s too basic so that most people are already relying on other extensions. In any case, feedback would be good to have!

FWIW, I won’t miss hyperlinks if you put them in another extension-- I’ve put aside the idea of trying to do hyperlinks with Common Commands Sidebar unless/until UGI and Flexible Windows become compatible at some point.

Bordered windows: that is not the same as scrollbars, is it? Because scroll bars would be nice. It’d be nice to be able to refresh an extra window every turn without worrying about the More prompt getting in the way. If not, I haven’t missed borders, because I’ve never tried them.

(I don’t know what you’re referring to as far as input phrases and command prompt phrases, so I guess I’m not missing those either?)

I just haven’t tried Flexible Windows myself in the post 6G60 world (though I put your WIP in my own WIP CYOA extension as a stub just to see if its presence broke anything, and it hasn’t/didn’t) but on paper, I’m not screaming about any of the changes, and I just wanna say thanks again.


bg: Are UGI and GEP incompatible? That wouldn’t surprise me. I think I will create a wiki page (probably in the i7/extensions Github repo) to look at all the parts of the Glulx/Glk ecosystem and how they’re supported by extensions.

Bordered windows were an extra type of g-window that would automatically create four graphics windows to act as borders around it. You could set the thickness and colour of the border. Not terribly useful or attractive, but it would also be really easy to recreate as a separate extension.

I actually haven’t tried it…I just assumed UGI wouldn’t be compatible with FW. I forget exactly what zarf said that led me to think this, but I’m only guessing.

Oh, I think I experimented with creating windows next to another window in order to create margins. It looked really bad in interpreters that had scrollbars on the extra windows, so I decided not to use it. Don’t remember if the extra windows were graphics windows though.

And seconding what Wade said–thanks for all your work on this!

Yes. UGI manages all the Glk input state; GEP exposes it for the game to manage. They are fundamentally different approaches.

Somewhere in the future of UGI evolution is an update to understand multiple windows, and then a version of FW that talks to it appropriately.

Is there a specific reason for automatically clearing windows when refreshing them? I need to keep a window’s contents more often than not (for example to print what is happening every turn, or to show a picture over the previous one in a graphical window), so I have to replace the prepare for refreshing rule in all my projects.

I find it easier for the author to choose when he wants to clear the window than to choose when he does not want to clear the window (hope it’s clear).

Anyway, that’s not a big deal, and the extension is great, but I was wondering.

Well that’s its purpose, to clear and redisplay the windows. So the question should be instead, when is it happening that you would prefer it didn’t?

(The only common time when it might be unwantedly refreshing is when the player resizes a window - however that doesn’t seem to happen in my tests… something weird is going on there. I wonder if Glulx Entry Points is not handling the event when the window argument is NULL?)

Well, I don’t want it to happen when I refresh the window. :stuck_out_tongue:

First case:
One of my game have a multiple characters moving and performing actions. All the text describing this is displayed in a side window so that the main window is not cluttered. The player should be able to review what happened previously, I don’t want it to be cleared.

Second case:
I’ve got a graphics window which display the picture of the location and the things being interacted with. I want the pictures to “stack”, without clearing the window each time.

As I said, it’s just a matter of replacing a rule. If I’m the only one bothered, then it means it’s better the way it is and that I’m the exception (I still think it’s more flexible to clear only when the author writes it).

I saw too that Flexible Windows is supposed to refresh the windows when resizing, but that it didn’t happen. That could indeed be a nuisance.

Are you manually refreshing the windows? The rulebook is intended for situations in which the windows get corrupted (usually from resizing) and need to be refilled. When I figure out why the resizing isn’t working I’ll probably limit it to graphics and text grid windows.

Here is the simplified code for what I want:

First case:

[code]Every turn: refresh the side window.

For refreshing the side window:
follow the blah rules

A blah rule:
if Bob is hungry, try Bob eating the apple.
[and so on][/code]I’m aware that’s not good (what if the window refreshes because the user resizes the window ?) but I haven’t found another way to make the text that result from “try Bob” appear in the side window. I didn’t even find a way to say "Blah" in the side window

Second case:

[code]The currently shown picture is a figure name that varies.
A thing has a figure name called illustration.

Carry out examining something:
now the currently shown picture is the illustration of the noun;
refresh the graphics window.

For refreshing the graphics window:
display the currently shown picture in the graphics window.
[this phrase calls some I6 that shows the figure in the graphics window][/code]In this case I want the next picture to be shown over the previous one, so the window should not be cleared.

And yes, I manually clear the window when I need it, like in the 6G60 version of Flexible Windows.

I didn’t find a way to write something in a window without using the refreshing activity. Is there one?

Ah, well that’s easy, just use the “focus [window]” phrase. Then use “focus the main window” to return back to the main window when you’re finished. Refresh rules definitely shouldn’t be doing anything that would change the game state.

Graphics windows don’t use focus like that, so instead of calling the refresh rule you can just directly run your graphics code in your carry out examining something rule.

Aaaaah! So you can just focus the window! I thought there were some traps in the way the window system was handled, and that you had to use the refreshing activity to avoid them.

I guess I still have to keep the refreshing rule with the graphical window, so that it displays the currently shown picture in case the window gets resized or something.

It’s a shame there is no documentation for the extension. It’s so useful.

Anyway, thanks!