So what about the fyrevm-web thing mentioned above? Isn’t some of this exactly what it’s doing? Or trying to do?
I’m getting the feeling that there’s a lot of disconnected work going on rather than a gathering of forces. That could be completely wrong on my part.
That’s Dave Cornelson’s project to try to do something a bit different: it uses the same underlying virtual machine architecture (Glulx) but with a different I/O layer (FyreVM instead of Glk). Glk was an attempt to define an I/O layer that would work in the desktop world as well as the web: FyreVM is an attempt to re-think the text adventure display model in terms of modern web technologies (I’m putting words in Dave’s mouth here).
People work on whatever they’re interested in: sometimes that will be building on previous work, sometimes doing something completely new, and sometimes a combination of the two. I don’t see anything wrong with that.
I completely agree. I never said there was anything “wrong” with it necessarily. But if there’s already been a great deal of investment in work in a particular approach it might be worth seeing if some focused effort towards taking that to its conclusion (or a conclusion) is worth it. Sometimes people choose their own path because they aren’t aware of the existing paths that might be more fruitful.
As others have noted, there’s a lot of half-completed or partially-started work out there. Clearly a lot of experimentation, which is healthy for an ecosystem. But there’s also nothing “wrong” with a focused effort in a relatively few directions rather than a defocused effort in a series of potentially orthogonal directions.
For example, in your phrasing if “FyreVM is an attempt to re-think the text adventure display model in terms of modern web technologies”, it looks like this is something that TADS 3 tried to do with its own model of the WebUI. It sounds like there are at least two implementations of this idea to learn from, which I think would be interesting, particularly if, as you said, the previous styling system of Glk was being changed more to an HTML/CSS type approach.
Keep in mind I’m an outsider looking in. There’s not a lot of good roadmaps, that I’ve found anyway, to what paths the community has tried, not tried, wants to try, etc. It’s only by providing a few prodding questions that you can even start to gain a semi-coherent picture. That’s currently the phase I’m in.
Regarding areas that need help–there’s a to-do list for interpreters (among other things) that was put together a year or so ago.
If you want to know more about who has contributed to Inform 7, its page at IFWiki is a good place to start.
It’s actually your final item on the list that I’m talking about avoiding. Z-code already has a set color opcode and Inform 7 already has a syntax for changing text colors - and I pointed to Gargoyle’s function garglk_set_zcolors() - which was actually implemented in some of the existing Android apps as a way to get Z-code color into the fold. Z-code Inform 7 knows how to produce these color calls without any extensions at all. Basically I mean the foreground text colors. Then, if someone wished, they could add the extra styles to Glulx extensions that already use User1/User2 and and treat them as an extra set.
It’s nice to say ‘abandon stylehints’ - but that’s overlooking the point there are hundreds (thousands?) of stories out there already compiled, without source code, that make use of stylehints! My focus right now is on Glk + Interpreters (multiple interpreters) and easier portability. It was an observation rooted in experience born out of reviewing Android apps with 3+ different implementations of freshly built Glk type layers. stylehints are difficult because the properties have to be set at the time of the window creation - and combining that with a very small set (user1/user2) has left Z-code colors closed out of the Glk system.
This year’s hot Christmas gift was a Classic Nintendo with a modern HDMI port to hookup to a fresh television set. I honestly have to say that the 3 major Android Interpreters (Text Fiction, Son of Hunky Punk, Twisty) seems to be under the keys of developers who are perfectly content with Z-machine only. Two of them have played with Glulx (Twisty, Son of Hunky Punk) but have left it on the back burner for years. I think it’s a mistake to slight z-code which has colors as a first-class opcode. It isn’t going away.
That’s not going to work. If you’re compiling to Z-code, then either you write Inform 6 directly, or the Inform 7 code is compiled down to Inform 6 syntax, but ultimately in either case changing the text colour in Z-code will reduce to an Inform 6 line like
@set_color 3; ! use red
But when compiling to Glulx, that means nothing to Inform 6: it will just generate an error. Instead you must have one or more Glk calls to do whatever you want. If you look at the I6 template files (those ending in .i6t) in the Inform 7 installation, you can see such calls are emitted for Z-code only. Whatever you do, you are always going to have to provide some sort of Inform 7 extension to actually make calls to make the color change happen. There is no way to avoid this.
A .z8 file is ALL Z-code! It doesn’t emit Glulx to do this! I’m talking about z-code here, targeting .z8. Again, I know all this. And my proposal change (~20 lines in Glk.h) is STRICTLY between Glk and Interpreters. Inform 7 does not need to change. What you just described, “it will just generate an error”, is exactly what happens today in Inform 7 IDE!
inform7.com/learn/man/RB_12_1.html
say " [item] ([front side of the item]/[back side of the item]): [if the item is locked][green letters]LOCKED[default letters][otherwise][red letters]UNLOCKED[default letters][end if]";
Glk can not deal with this public syntax once you go beyond 2 colors! That’s the reason Fizmo Interpreter uses an out-of-band call to Gargoyle garglk_set_zcolors to get more than 2 colors - when it uses Glk for everything else!
Let me point out what may not be obvious context of this requested change: When writing an app for Android tablet or Ubuntu desktops - most of the work goes into Glk! The interpreters are already out there and decade-old C code compiles fine. It’s Glk that is the middle API that is all the labor of making an application. Son of Hunky Punk is the perfect example of this - it has TADS, HUGO, Z-code interpreters, Glulx interpreters - almost all the labor of adapting Interpreters to a platform is in the Glk work! We have multiple Z-machine interpreters (like 10 of them) and multiple Glulx interpreters (Git and Glulxe) that easily compile and adapt to any platform.
P.S. Just yesterday working on this more, I would also say that we could have one MORE style to the list. In addition to Z-code colors github.com/BroadcastGames/Infor … fac2ba40b9 I think one more style of style_WindowColour - so that Gargoyle’s technique of setting window background color (off Normal text background) could be normalized in Glk without interfering with style_Normal like it currently does.
Zarf has in the past allowed others to have a range of function codes and gestalt selectors to write external specifications for. So we could formally specify the additional Garglk functions. That would probably be an afternoon’s work. The trickier thing would be getting enough (or any) Glk libraries to commit to implementing them. If it would really help with your work on an Android terp for both Zcode and Glulx then I’d say that wouldn’t be a bad thing to do, even if our real future focus will be with the CSS extension. Zarf has reserved a range for me already so I could do up the spec for this.
However if you are still thinking of using remglk for the android app then a subset of the CSS functions would be more productive. I am already thinking about that for ZVM and Lectrote. This would not be as quick a process as formally speccing the Garglk extensions because we would want to ensure that it will fit with the eventual CSS extension. So rather than using the range of codes reserved for me we would want to suggest that a core subset be implemented in the base range of codes.
When it comes down to it, connecting RemGlk (JSON) with the idea of GlkHTML shows that this is a good way to bring Z-code colors into the fold. RemGlk is essentially treating each style_ like you would in CSS with a class=“style_User1” and class=“style_Normal”. By promoting Z-code’s 11 colors into the fold as their own defined styles - you essentially have a way to standardize the Glk to app interface for colors in a way that requires very little code changes to Interpreters and apps. As both ends of the spectrum already have to know how to deal with style changes to do bold, italic, etc at any point in the text stream. Now you are just making these 11 colors official in some kind of high regard for the history of Z-code in Interactive Fiction 
Glk 0.74 styles are around an integer index that allows 32,767 style_ (RemGlk uses a short) of which it only uses 10. And I think Z-code deserves enough legacy respect to be granted it’s own foreground text color pallet of 16! I think it would also have immediate benefit to other interpreters (yes, even Glulx) who are stuck with only 2 ( style_User1 and style_User2 )! All this chicken and egg talk (who implements first) is nonsense to me because it seems blindingly obvious to me that Z-code 11 colors were slighted from the get-go. The chicken came first (the eggs are the Inform7.com link I provided showing how to tell a Z-code interpreter to lay red or green eggs, as in say " [item] ([front side of the item]/[back side of the item]): [if the item is locked][green letters]LOCKED[default letters][otherwise][red letters]UNLOCKED[default letters][end if]"; )! By promoting a well known and well implemented color pallet to first-class style_ choices you even tackle things like visual impairment substitutions if an app so wishes to implement this. From a player perspective, it allows them to choose what they want just like they can for say font family.
If we were to go with the CSS functions there would be no need to define any further styles, because it is set up to be extensible. A Zcode user of glkote would just provide their own css file. Those using the functions in Glulx can provide a stylesheet in the blorb.
Seeing as there are at least two of us who could make use of it, I have started an issue for the css subset: github.com/erkyrath/glk-dev/issues/7
I think that about sums it up perfectly. To clarify:
— fyrevm-web rethinks the text adventure display model in terms of modern web application development technologies —
The primary driving forces for my work are:
All of the base IF platforms are pushing into web implementations, but you have to remember they all started as desktop platforms. These web implementations are add-ons to fairly old 90’s architectures. Even my efforts with fyrevm-web are tied to Inform 7, which could still use more separation of concerns within its own architecture (all event output should be handled centrally so it can be trapped and managed).
And IF development is very much like a herd of cats. We occasionally line up and play together, but more often than not we’re busy hiding in a box taking a nap.
I’m starting to get there with my Glk extensions, but there’s a lot of legacy code to try to keep working. My tool of choice is now the old I6 directive Replace, so that I can intercept the Glk functions directly. (Unless you call them using the opcode that is.)
I don’t know what would need to happen for fyrevm though. It would really hurt to make a VM that had both Glk and channel IO, or as much as it can have both.
David’s work is where I started early in my learning and working with it had a great influence on me. In many ways, he is doing what RemGlk is doing with existing .z and .ulx code. Stripping out all the legacy Glk colors, sound, graphics and turning every window into a stream. RemGlk even treats each window as it’s own independent input source (so it is, in a way, a bidirectional Channel for Input/Output). If you think of every Glk window as a stream, window rock 700 is audio commands, window rock 800 is phone vibration commands, window rock 900 is tilt sensor, you really then just come up with command protocols and convention for directing an orchestra. RemGlk breaks down in Glk’s concept of “waiting for input from player, one at a time”, but David has work on concurrent designs.
David’s work is to make the Interpreter (Glulx in his case) the orchestra director. The conductor is setting the timing and keeping the brass section in sync with the drums. If it’s Pink Floyd or Styx, the laser lights and video presentation 
youtube.com/watch?v=ZIhPdW9LgK0 It’s a remote-friendly design in that it isn’t tightly coupled as to producing the actual assets (graphics, sounds, etc). It focuses on remote communications channels and letting designers/artists do their work much more like the relationship to the orchestra conductor. At least that was my takeaway of concepts from it.
This discussion is more useful without me in it – 
– but I’m curious then:
What’s the benefit of two approaches – RemGlk vs fyrevm-web (if that’s an appropriate distinction) – rather than the coordination on one of those approaches?
Believe me, in my career I’m all for having more than one option to choose from. But it sounds like there’s some really smart people doing some really smart things – but all in different areas that are not compatible and may or may not overlap. Imagine if Inform 7 had two or three different competing versions that didn’t quite work the same. There’s a reason to specialize a bit on a platform, after experimentation has been done to determine viable and non-viable approaches.
I see things like RemGlk and fyrevm-web as platforms – with a possible ecosystem – but with different smart people working on them. I’m just wondering what would happen if those smart people combined forces on a project and took it as far as it could reasonably be taken.
Is my pointy-hat manager side coming out? It is, isn’t it? This discussion has been very enlightening so I’ll step back into the shadows now.
My archaeology of David’s work is that he went the Skunk Works approach of an independent laboratory set up offsite. He published descriptions, extensions, and shared source code. He had an idea that not many people were interested in coding on - and he funded it and labored on it for his own projects and some third-party people did use his work and independently publish stories. He has been building his own set of experience with his ideas of shedding the old skin of Glk and the 80x25 screen model. He has been working on it for many years. It’s common for a small team like that to prototype and build things from scratch that others would not do. David could have left Inform 7 ecosystem entirely behind and went with other competing systems - I’ll speculate that he likes the Inform 6 / Inform 7 authoring tools much like I do when it comes to these choices.
Andrew Plotkin’s RemGlk is at the opposite end of the spectrum. It’s goal in life is to interface to the legacy C code and allow you to leverage (link with) established interpreters (many 10 years or older, For example, Evin Robertson’s Nitfol is from 1999 and I’m using it in my Android app work today) that are already using Glk interface. It furthers the vision of Glk…
David abandoned Glk entirely. RemGlk is a lot like the International Docking Adapter (IDA) en.wikipedia.org/wiki/Internati … ng_Adapter that allows Quixe + GlkOte in a web browser / HTML5 to interface with compiled C code interpreters through intermediate data representation (JSON). In my case, I am trying to view JSON and RemGlk as the API instead of Glk tightly coupled. I’m not using HTML or a web browser at all. I found it much easier to learn RemGlk’s JSON than working with Glk C programming directly. Both “channel” I/O via streams in their own way (if you view each Glk window in RemGlk as a stream).
Further testing of the idea of promoting Z-code’s 11 colors to first class style_ in Glk has proven poor. As it would only create more conflicts in mixing bold and italic with colors. Since the Gnome Inform 7 build 6M62 IDE on Linux can’t even be consistent with Gargoyle or Frotz or Fizmo on Linux (nor is the Gnome Inform 7 IDE consistent with published Inform 7 documentation) - the problems point to a lack of published Inform 7 source code for 6M62 that demonstrated mixed bold, mixed italic, mixed colors, etc. The issue isn’t that we are in 1978 with the newly released DEC VT100 terminal and it is unable to mix italic and bold, the problem is testing and confusion! Clearly Linux has no trouble with mixing bold and italic, it’s the implementations of Glk in software. sigh. Here is source code for Inform 7 6M62 z-code / z-machine mixing of colors, fonts, languages, etc: raw.githubusercontent.com/Broad … Styles0.ni
That would be excellent.
Extending other Glk libraries to support zcolors shouldn’t be too difficult, I think. Here’s how it was added to Gargoyle in the first place: bitbucket.org/jmcgrew/zlr/commi … 3d2a728427
Thank you for posting this, hadn’t seen it and it provides some clarity. Let me say I understand the idea of ‘hints’ being in the name and allowing interprter apps the freedom to ignore colors if they so wish. That isn’t actually the problem! The problem is buggy implementations and inconsistencies. The most glaring inconsistency is that on Ubuntu Linux (Gnome) you have two major apps that run both Glulx and Z-code/Z-machine that do it very differently: Inform 7 6M62 Gnome IDE itself has severely broken implementation of zcolor… it does in fact attempt zcolor, but it does not do them like Linux Fizmo and Frotz does them on the same system - nor like the inform7.com website documentation example itself implies ( say " [item] ([front side of the item]/[back side of the item]): [if the item is locked][green letters]LOCKED[default letters][otherwise][red letters]UNLOCKED[default letters][end if]"; does not work correctly in the IDE interpreter)!
What struck me most is how motivated authors are to stick with Z-machine only apps. I understand the desire to play legendary Zork and other games, but in a way there has been a breakdown of motivation to tackle Glulx. And when I dug through all the code it was pretty clear to me the lacking colors support in Glulx over the years and the limitation of only User1/User2 was leading to wasted time by both software coders and story authors. This comes to me from a lot of reading of posts via search engines. And, of course, Android app source code commits/etc (as I mentioned several times, Android had a working Glulx interpreter with the most flexible of legal licensing - Incant github.com/qpliu/incant - that the community practically ignored since 2014).
My Glk “bring it into the fold” wishlist is that: Out of high regard to it’s legacy, the 11 or 13 Z-code/Z-machine colors be brought into the fold and examples given of how to implement them and a ‘reference Glk implementation’ be cited. Second, I think bold, italic, and underline all need to be distinguished from each other in Glk if an application so chooses. Yes, on a Frotz or Fizmo VT100-type ncurses approach they can choose to make [ bold == underline, underline == underline ] but on a modern complex system like Android it should be allowed that Glk is more clear that the story author requested one or the other and to distinguish them. Can we sneak in strikethrough? Third, the option on desired behavior of mixing these same attributes. If a platform has the capability of doing color, bold + italic, bold + underlined, bold + underlined + italic, color + bold + italic + underlined + strikethrough, how would Glk indicate to mix them and how should they appear (reference implementation, even if only a mock-up screen shot image or HTML page). If you listen careful, I’m not putting emphasis on a “nice to have wishlist” like font family or other things. And, implied fourth, bring the zcolor option into the fold for any other interpreter to use (Glulx, etc) beyond style_User1/style_User2. I’m really talking about basic consistency here between well-established interpreter apps multiplexing one Glk to multiple interpreters - and the Inform 7 build 6M62 Gnome IDE vs. Gargoyle on Gnome illustrates this inconsistency.
I understand that there is a desire for a CSS Glk-styles The Next Generation. But Android doesn’t know how to process CSS, and neither does ncurses. In many ways, Android’s native (first class) text output is actually very much in the spirit of the VT100 (ncurses) in that it allows you to take a string (words or prose) and apply bold + italic + foreground color + background color all on a character by-character basis! The world wrapping and justification take it all into account automatically (on hundreds of different sizes of screens with tricky issues like right to left Arabic السلام عليكم right in the same bold/italic schemes). Maybe people didn’t realize that a very modern text output system (Android) was built like that (reference: SpannableString github.com/BroadcastGames/Infor … Styles0.ni ). Thank you, and Happy New Year. May we all have a Glk integrated होली Holī-Day
P.S. This was an actual news headline of 2016: androidauthority.com/whatsap … ng-680598/ - let that sink in for someone who has worked with VT100/VT102/etc type terminals since 1978! You are looking at a system there that’s nearly identical to what Z-machine was doing! I understand the desire to go with CSS3 and HTML5 separation of concerns, but is that what you see people really doing there in that screen shot? They are encoding inline transitions - just like zcolor does. What is old has become new again
Since someone has asked for the Garglk functions to be specced, I’ll do that, though I won’t push for any interpreters to implement it. Note that without edits to Garglk, even it won’t report support for them (through the gestalt function)!
Speccing what is already out there in the wild is one thing, but taking Glk in a new direction is another. While theoretically adding additional stylehints would not be impossible, we really should not. It hasn’t been previously requested by either story or interpreter authors, and it would add extra complexity because authors will want to be able to ask the terp which new stylehints they support. (And stylehint_distinguish is already a pretty terrible interface.)
CSS is much better, and it’s what Glk’s inventor wants. It’s extensible, very easy to implement for web based interpreters, and not impossible for others (CSS parsers are available in most languages.) If we’re going to expend considerable energy on an improvement to Glk then lets do the extensible option.