I started this month working on a GlkOte alternative implementation called AsyncGlk. Some code is borrowed from Zarf’s original GlkOte, but I’ve reorganised it and changed to TypeScript. At the moment it’s only a rewrite of GlkOte, but I plan to work on GlkApi in the future, which will allow Parchment to finally move its file system to IndexedDB, as well as connecting to Dropbox/Google Drive etc.
Aside: this is my first proper TypeScript project, and I have to change my perspective on it. I said recently that TypeScript didn’t count as having proper algebraic types as you have to manually handle tagged unions. And that is true, but it’s nowhere near as un-ergonomic as I thought it would be. Actually most of the time the code feels clean, potentially even cleaner than Rust sometimes (I really dislike if let.)
So I think it’s largely feature complete now, though no doubt it will have bugs. It is already better on mobiles than the original GlkOte. If anyone is able to do any testing it will be greatly appreciated. You can find the demo here:
The Inform 7 template has not been changed to use the new GlkOte library, but I will do that in the future.
But I do have something else to show you: single file Parchment! This is a Parchment packaged into a single HTML file, which includes interpreters for Glulx, Hugo, TADS, and Z-Code, and should work offline even from a local drive (file: URL).
A huge thanks to @dfabulich for giving lots of feedback and testing help!
I really like the single file version. This makes the process to bundle games pretty straightforward if you’re not using Inform 7 but e.g. Inform 6 or any of the other mentioned systems. I do have a script that relies on @zarf’s ifsitegen.py but it’s currently a Windows based script and since the BuildTools package I am maintaining is Linux based, I would definitely switch to this new effort.
I don’t get it running on Windows though either. Not sure if my problem is the same you face but when I try to open a local file, I get this:
Single file mode has been fixed (by embedding a single font file; the browser can synthesise the rest, and it’s only 220KB)
Fixed Counterfeit Monkey and other games which open a collapsed graphics window
TBH, single file mode isn’t ideal for that situation as it includes lots of interpreters you won’t use. You could strip them out of the HTML I guess, but the Parchment for Inform 7 package is probably better suited. ifsitegen.py isn’t a Windows script (I’m not even sure Zarf has a Windows device!) and it should work fine in Linux.
Thanks for the fix, which is much appreciated. I’ll give it a go later
And sorry for being not precise enough with my statement. I am maintaining the Puddle BuildTools, a collection of interpreters, utilities and scripts that allows transforming Inform 6 sources to ready to use distributions, mostly disk images for the home computers of the late 80s and early 90s. Currently 25 classic systems are supported (a few more in the works) + modern PC. I am working from a WSL2 environment, which integrates a full featured Linux distribution in your Windows System. I can invoke Windows applications through Bash scripts or fire up Linux applications from within Windows. I try to keep things as much as I can on the Linux side, which makes the whole build system work for someone with a regular Linux distribution as well. @mulehollandaise for example, who used the system for the development of Tristam Island.
Anyway. I know of course that ifsitegen.py is a Python utility, so in theory it works well for any host that has a Python interpreter. Practically it requires an existing Inform 7 installation and it looks for it on the standard path, defined by your host system. The Debian system I have set up for WSL2 does not have a desktop environment installed. There is no need for the burden of a desktop environment when all you need is a console to pursue your IF development endeavors. To make ifsitegen.py work under Linux, one needs to install Inform 7 for Linux, which is Gnome based so if I want to install a package which I am actually never going to use, I would also install a full-featured desktop environment which I am not going to use either. That’s quite some overkill only for the purpose of bundling a platform independent interpreter with your game’s modern PC variant. Instead I went for the lesser evil and installed Inform 7 on my Windows host and from my Linux I use a Bash script to fire Python under Windows to bundle my game, using the Windows installation of Inform 7 then for ifsitgen.py as a basis.
This works for me. But it won’t work for someone on a real Linux. But the real problem I have with this is that I only use Inform 6 and in turn I don’t use Inform 7. Still I need to install it to make use of ifsitegen.py. Yes, I could do everything by hand but I am a friend of automating as it saves time and makes things very convenient, especially when you are rolling out a new release for 26 systems, there is no way anything in that process can be manual.
In an ideal world, I’d love to wipe Inform 7 and bundle the z-file together with a single file interpreter, which essentially is what single file Parchment is. I agree it that there are terps in it which you won’t need, still it would a whole universe of overkill less than the solution that I currently have at hand.
Sorry for the detailed explanation but I hope this makes my statement being understood better. I just look at this from a very different angle, under a different light.
You should be able to use the Inform 7 Linux CLI package with ifsitegen.py. You shouldn’t even need to install it, and you could probably identify which files are needed and just bundle them into Puddle. I think it only needs the Templates folder (but nested within a few other levels of folders). (Or you could hack the python script to just directly access the bundled Templates folder and not go searching for it.)
I just tried it, and I can confirm that all you need is the relevant intepreter and website template directories in some_directory/Internal/Templates and the following will work:
ifsitegen.py -a some_directory output.ulx
No other part of the I7 toolchain needs to be locally available for this.
AsyncGlk’s WebGlkOte has been in use in Parchment for a year and a half now, and I’m really happy with it. But the other half of the Glk API is the GlkApi library, and Parchment is still using Zarf’s original implementation.
I actually finished my own implementation of GlkApi about 11 months ago, but even though it passes all the Glk unit tests, it’s still got a few bugs, so I haven’t switched Parchment to using it. But this week I realised that Parchment could include both implementations, using Zarf’s by default, but use my new one if you manually switch to it. So that’s what I’ve done today. If you go to this URL you can opt in to test my new GlkApi library:
If you’re able to test it that would be great. Bugs can be reported here or at Github.
At this stage there’s really just one major thing which is missing, and that’s autosaves. But ignoring that (it’s not strictly part of the Glk API), it should be largely working. I’m hoping the bugs that remain are fairly minor, and hopefully not game-breaking.
I’ve fixed that start-up problem with ZVM and the new AsyncGlk library. More bugs may remain!
In particular, I just realised one issue is that existing Quixe or ZVM code may be accessing the internal properties of objects like windows or streams. If the VMs were written in Typescript they wouldn’t be able to do that because the Glk objects are ‘opaque’ classes, with no exposed properties. But Typescript doesn’t actually hide the internal properties so you can still access them from Javascript. If there are some obscure parts of Quixe/ZVM that access internal properties of Zarf’s GlkApi then they might break with my new GlkApi. But the good thing is that bugs like those are pretty easy to fix, it’s just a matter of detecting them.
(I really dislike 
