Setting rocks in Flexible Windows extension

Hey Erik (or Jon?)… not sure who maintains Flexible Windows these days…

Thanks to the wonders of zarf’s quixe interpreter, I recompiled Rover’s Day Out and managed to release a standalone quixe website for it here:

zarf helped me manually tweak the glk CSS so that custom-style-1 was blue and monospaced, as all the meta-speak is supposed to be. I’m thrilled that it works!

I then set out to make the temporary BSOD g-window have a blue backround. The proper way to do this is by addressing the rock-number in CSS, i.e.

.WindowRock_210 {
background-color: blue;

This is working for me, only because in my particular glulx binary the rock number just happens to be 210. But zarf and I agreed it would be a lot more elegant if I could set the rock number on the g-window to a known quantity, and thereby know exactly how to create the CSS. I tried to do “The BSOD-window is a g-window. The rock-value of the BSOD-window is 1729.”… and it compiled. But apparently the rock-value property is read-only?

Hey Ben, the rock-value property isn’t read-only, but you can’t change it until after the allocate rocks rule runs (in “when play begins”). This is all it should take:

When play begins: now the rock-value of the BSOD-window is 1729.

Of course, you also need to be sure that you’ve changed it (1) before opening the BSOD-window for the first time, while (2) ensuring that your manual rock number doesn’t conflict with a number assigned to another window by the automatic routine (that is, the allocate rocks rule mentioned above). As long as you don’t have 10 or more custom windows, any number 300 or above will be enough to guarantee that. If you only have the one custom window, then even 210 would be OK.

(The allocate rocks rule starts at 200 for custom windows and goes up by 10’s: 220, 230, 240, etc.)


Would it make sense for the allocate rocks rule to leave rocks alone if they’re already set to a nonzero value?

This is going to be a standard way to associate styles with windows in the CSS.

I don’t see why not. The important thing about rocks is they need to be deterministic, which of course, setting them by hand would be.


Here is a new version of the rock-allocation routine, which I’ve added to my working copy:

When play begins (this is the allocate rocks rule): let cnt be 200; repeat with item running through g-windows: if the rock-value of item is 0: set item rock to cnt; increase cnt by 10; now the direct parent of item is the direct-parent of item; set main-window ref.

The only thing that gives me pause is that you can now screw up your rock numbers, since some of them can be assigned manually while others might be assigned automatically. Since Glk doesn’t complain when two windows are created with the same rock, so you could very possibly overlook this. Maybe we might add something like this in a not-for-release section:

When play begins (this is the rock validation rule): repeat with item running through g-windows: let L be the list of g-windows; remove item from L; repeat with compared running through L: if the rock-value of item is the rock-value of compared: say "***Warning: There appears to be a conflict in the rock numbers of the g-windows '[item]' and '[compared]'. Assign rock-values manually to 210 and above to avoid conflicts."; stop.

There is probably a more elegant way to compare properties, but I’m not sure what it would be.


It’s technically legal (for the Glk library) for two windows to have the same rock value, but the I6 library code can’t cope with that. So a check like that is reasonable. Sadly N^2, but most games won’t have a lot of windows, and it’s just once.

OK, I’ve uploaded a new interim version of Flexible Windows here:

In addition to the two routines described above, this includes a couple of other minor fixes. I’d like to wait a bit before submitting this to the library, to see if any bug reports roll in as people use the previous version. What do you think, Jon?


Looks good to me.

The only thing I’d say is, in the documentation, we should probably advise people to manually assign rock values ending in a “5”, since it’s harmless to do so, and it’ll somewhat lower the possibility of a rock-clash.

We may also need a quick sentence explaining what a rock is…!


Good points both. I’ve incorporated them into the docs.