Hmm, if those heuristics could be clearly defined then we could go with them if you think it’s better. But it looks like Spatterlight completely fails test 5, so maybe the heuristics aren’t so great. If you think test 5 makes sense that is.
! Test 5: Use garglk_set_zcolors after clearing the window
Reset();
glk(42, mainwin); !glk_window_clear
print "Test 5: Use garglk_set_zcolors after clearing the window.^^The function call should have no effect.^^Press any key to continue.";
garglk_set_zcolors($F4CA16, $800020);
Wait();
Seems like both Garglk and Spatterlight when given a background colour immediately before glk_select will change the whole window background to it. This feels very wrong to me. We could specify that as the behaviour, but it makes much more intuitive sense to me that window background colours should only be changed when the window is cleared. These terps are retroactively changing styles. Which is probably a feature some authors would love, but not when it’s so unpredictable.
Yeah, I don’t mean that Spatterlight’s way of doing it is good or anything, just that it is so complicated that I hardly understand it myself. It would be great if it could be simplified, but it would probably have to be redone from scratch.
EDIT: By the way, test 5 makes a lot of sense and uncovers a bug in Spatterlight.
EDIT 3. It would be nice to have grid window versions of these tests as well. I’ll see if I can work out how to do it myself.
EDIT 4. Right, grid version. The text about the correct behaviour is not changed from the buffer window version, so it might be all wrong.
Differences in Gargoyle: In the grid version, the margin colour is not changed to blue in test 1. Test 2 actually succeeds in the grid version while it fails in the buffer version (wrong window background colour.) The other tests have identical result.
We could add extra tests for grid windows if you think it would help. Probably would be best to, for the sake of comprehensiveness.
So the stylehint margin method is strictly for setting the hints of buffer windows. The fact that it’s broken in test 1 in Garglk is, I think, a bug, seeing as it works in test 2.
Should the garglk_set_zcolors method also work for grid windows? My suggested rule above said no. We could say that the rule is the window type doesn’t matter, but I’d worry that it would result in the margin changing to the colour of a status window. Or we could make the rule more complex, and say that clearing any buffer window after garglk_set_zcolors will set the margin, or clearing a grid window after garglk_set_zcolors if there are no open buffer windows. Then if someone wants their whole game to be in a grid window the margin colour will be set, but not if they’re just clearing a status window.
Sounds reasonable. Many Z-machine abuses (Tetris and so on) use only a grid window.
A complete grid window Zcolor test should run all the tests in a standard setup as well, with a one-line status window above and a main buffer window below.