Your demo isn’t setting an initial white background before the main window is first opened.
That doesn’t seem to trigger the bug, either. In the force-white branch, I renamed “Default Room” to “White Room”, and I forced the background color to be white.
I haven’t tested it, but I meant before your initial glk_window_open call.
And I don’t know what the glk_stylehint_set calls in EnterWhiteRoom and EnterPinkRoom are meant to be doing. All they can affect are the page margin; the stylehint_TextColor calls are entirely ineffectual.
Sorry, you’re right! That was my mistake. 
(A lot of the weirdness here was following Gargoyle’s implementation, which is buggy, and confused me about what happens when updating stylehints after a window is open.)
https://github.com/dfabulich/glk-window-background-immediate/blob/force-white/bgcolor.inf now sets the normal background color to white before the window opens (and sets the foreground color to black).
And, when navigating from room to room, if glk_window_set_background_color_immediate is available, we now just call that, without messing around with the open window’s stylehints.
To make this work, as you predicted, I had to make glk_window_set_background_color_immediate update the normal background color stylehint, live. I also had to ensure that when styles like Header and Input have no explicit background color set, they would automatically inherit the Normal background color. (If someone does set an explicit background color for Header, that text will retain its explicit background color after calls to glk_window_set_background_color_immediate.)
Now, I think, the implementation is sane.
(I did spend some time investigating the idea of live updating foreground text. In Spatterlight’s NSTextStorage implementation, I think that would inherently be kinda slow on long text buffers (O(N) of the length of the buffer). That may or may not be a deal breaker, but IMO it’s one more point in favor of treating the window’s background as “special.”)
This is an issue, as Flexible Windows sets the bg colour of all styles. I think it might have been Windows Glk that required that.
But I think this has a simple solution: we can require that any implementation supporting the new function must also implement transparent/inherited backgrounds for non-normal styles. Flexible Windows could then check the gestalt for the new function. If it’s supported then it would only need to set the bg of the normal style. If it’s not supported it can continue setting all styles.
For the record, I just posted on the Glk CSS thread; I now think we should support this just by making glk_css_inline_set apply to the window.
1 Like