Yha, I’ve gotten that message from reading here and the docs… but a lot of the existing stories (without source code) are out there. What’s needed is some examples of the ‘proper way’ to do things and a kind of guide of source code examples Do’s and Dont’s for authors of 2017 and forward.
My guess is that it wouldn’t take too much to add the proposed glk style functions to the GlkOte protocol (if it was limited to s and the paragraph system was not implemented yet.) For non-Glulx uses of GlkOte this would get you a lot of the way to full style support. With more work the JS interaction functions could be added, and with some custom JS for each engine the rest of the support could be added. And with that in place even Glk stylehints could be supported.
Here’s the code for the blunt approach of emit JSON for stylehint: github.com/BroadcastGames/remgl … hint_emit0 - it works fine in my application for getting the colors of user1/user2. Note that the extra JSON breaks remote-if.py wired to GlkOte currently. It doesn’t follow the convention of wrapping everything in JSON “type”:“update” with generation number. Even without that convention - not sure why it breaks remote-if.py , because the web browser console shows ‘Ignoring unknown message type stylesetother’ (which is good, it is ignoring what it does not support) - but it does seem to break on stories that emit it (CoSv3.blb is an example of breaking story, however ones which emit nothing like advent.blb work). For my app it is fine, but thought I should give a warning. Consider it a ‘proof of concept’ and not worthy of a pull request.
Quotation is a text style. [ Maps to Normal/"Quotation" ]
Gods talking is a text style. [ Maps to Normal/"GodsTalking" ]
Chapter is a text style based on Header. [ Maps to Header/"Chapter" ]
say "[Chapter]The Arrival Of Monkeys[/Chapter][paragraph break]"
say "They say, [Gods talking]'Look over [italic] there.[/italic]'[/Gods talking]"Are there any extensions / ways to generate these calls with Inform 7 6m62 + Glulx output?
No, the CSS proposal has not been implemented in any interpreter.
Defining I6/I7 phrases to make the appropriate Glk calls is entirely possible. The problem is just that no current interpreter supports them, so they’d be rather useless for authors.
If you’re asking about this in the context of adding style support to a Glk library, of course, interpreter support is irrelevant.
I’m trying to comprehend your statements, i’m not certain what you mean by “Interpreter”. Do you mean a “full app” that binds a Glk + Glulx interpreter? Right now, a lot of the Glk’s out there do not support style hints such as text color on User1/User2 (GlkOte: no, RemGlk: no, GlkTerm: no)… where ZMachine-only apps tends to have had text color for a long time. In terms of adding support to linkable Glk libraries, it would be great to have some actual Inform 7 generated .ulx files that call the proposed API and perhaps even provide some mockup screen images (or HTML mockup, doesn’t have to be images) as to how it would be expected to render.
Indeed, by “interpreter” I mean a Glulx interpreter attached to a Glk layer (since that’s what you’d put the Inform 7 output into).
If you want to generate style hints in the current way, using the fixed list of styles with their various parameters, you can use the built-in Glulx Text extensions.
I’m not discussing the ‘current way’. I’ve already published samples of the ‘current way’ with source code: github.com/erkyrath/glk-dev/wik … -style-api says that both can be implemented ‘side by side’. What’s lacking here is any compiled .ulx sample of the proposed API. That’s what I’m asking Dannii about.
It’s impossible to use in Inform until the API has been assigned function codes. That page is only a proposal, not a full draft for the next version of Glk.
Couldn’t an extension create a syntax in existing Inform 7 6M62 that emits the proposed Glk calls? An extension that lets you setup begin/end Glk call pairs like:
[not valid Glk code, just example of Inform 7 6M62 wrapping]
To say xxx0 -- beginning say_xxx0 -- running on: (-
glk_begin_style_name(1000, "xxx0");
glk_begin_style(1000);
-).
To say /xxx0 -- ending say_xxx0 -- running on: (- glk_end_style_any(); -).
To say xxa0 -- beginning say_xxa0 -- running on: (-
glk_begin_style_name(1001, "xxa0");
glk_begin_style(1001);
print "ALTERED ";
-).
To say /xxa0 -- ending say_xxa0 -- running on: (- glk_end_style_any(); -).
Green Room is a room. "Does this new style show?: [xxx0]here is the new xxx0 style[/xxx0]. Is [xxa0]style xxa0[/xxa0] the same?".Glulx Text Effects already handles calling glk_stylehint_set, but that API can only set those style hints before the window has been created. The proposed CSS system is completely different, and it will need a lot of work before it’s ready.
Technically if you had a block of Glk function codes then you could define some of them as experimental implementations of the proposal, with the intention to change them to the official function codes when the spec is stabilised. The @glk opcode can call any Glk function code at all. But that’s useless without an interpreter which will accept them.