No-one else commented on this, so here’s my take: Zarf has basically said that he’s abandoned Glk’s original “style hint” model for colours and styles in favour of a HTML/CSS model, so we can’t expect him to do any more work on it. This doesn’t mean that someone else can’t come up with something, which could be popular, but really it requires an “end-to-end” solution, consisting of
- A change to the Glk specification, and
- An implementation of that change in at least one popular interpreter, and
- An Inform 7 extension to use it, along with at least one example to demonstrate its use.
This is all rather a lot of work, but not impossible. The really open question would be how to change the Glk specification, as there are several possibilities that I can think of (there are probably others):
-
Just add a bunch more styles to the specification. It’s not completely clear to me what you’re proposing in the referenced GitHub commit, but it looks like basically this is what you’re doing. I would suggest they should be “style_User3”, "“style_User4” etc. so that all you’re saying is that there are more styles to play with, not that any new ones act any differently to the old ones. The advantage of this is that it’s pretty simple. The disadvantage is that it’s still not as flexible as the Z-Machine colour model, especially not the (admittedly not really ever used) arbitrary colour support included in the Z-Machine 1.2 spec (see the section on “@set_true_colour” in http://www.ifarchive.org/if-archive/infocom/interpreters/specification/ZSpec11.txt).
-
One step up would be to allow arbitrary numbers of user styles to be created. You’d need to add an extra Glk call that allocated space for another style and gave you back the appropriate index for it, something like
glui32 glk_create_new_stylehint();
This would allow arbitrary numbers of styles (up to some limit in the Glk implementation, possibly), but it does mean adding an extra function to the Glk specification, so an extra work step would be to add the appropriate logic to the dispatch layer so that the game could call the new function through the interpreter. Also, the result still isn’t as flexible as the Z-Machine colour model, since you still have to choose all the styles you need in a window before the Glk window is opened.
- A different approach would be to work around the limitation in Glk that the styles have to be set before the window using those styles is opened. You could, for example, have a Glk call that updates the style hints for a given window without changing the display of any previous text, something like:
void glk_style_update(winid_t win);
- A final approach would be to bypass the Glk stylehint model somewhat, and add an extra Glk call somewhat in the style of the Gargoyle extension you mentioned, which would set the text foreground and background colours directly, regardless of what styles are in use, for example:
void glk_colors_set(winid_t win, glsi32 fore, glsi32 back);
The advantage of this would be that it would be easy to write an extension to use this, as it would be separate to the style model as is.
In addition to all this, there needs to be some way for a game to test whether the interpreter supports the chosen extension: you can’t simply call an additional Glk function without knowing if it’s supported, as otherwise the interpreter will almost certainly halt the game with a fatal error. The simplest solution here would be to add something to the Glk Gestalt model: you’d need a new number for a new gestalt selector, ideally from Zarf, so that your extension could use Inform 6 code like
if (glk_gestalt(gestalt_StyleExtension, 0) ~= 0 {
glk_colours_set(win, fore, back);
}
I suspect to get traction someone would need to choose an extension approach, implement it in an interpreter, make an extension and then hope it proved popular.
