Front-End loader app to RemGlk - all Glk terps - dream wish

#1

Messy and rushed, as seems my fashion these days: Chris has recently made an entirely new set of Make files for all the backends to Gargoyle. It’s done in CMake and works with a variety of modern compilers and CMake is fully integrated with Qt Creator 4.3.1, Android Studio 2.3.3, etc! I’ve worked with Chris to get the cross-compile furthered for Raspberry Pi, ARM mobile phones, occasional MIPS CPU, etc. It’s great to have these modern organized make files, thank you Chris. github.com/cspiegel/terps

What my dream team wishlist next is a C code app in front of RemGlk. That does a few things that RemGlk does not do:

  1. Extract the blorb file. RemGlk knows how to internally read the blorb files but does not have an option to actually extract the image, sound, etc files to disk.
  2. Standard integer codes assigned for all know terp “engines”. 1 = glulxe, 2 = nitfoil, 3 = git, 4 = bocfel - you get the idea. These will be args to pass to the code before the entry point into RemGlk’s current main function. The main thing is that all apps and associated configuration files for all apps have a standard integer-based index as to which “interpreter” they want.
  3. RemGlk currently has a silent startup, waiting for an INIT. I think it should have a JSON protocol with a “hello” message (maybe an integer list of which terps it has available? their version number? and stock or modified?), and an option to “load story file xxxx on engine 2”, “exit”, etc.
  4. All the Gargoyle extra function API’s for color, story name, terp name become standard - and we have them emit a JSON message (where possible) to the UI app.
  5. Is there need for standardize save/restore in this proposed middle-ware, so that GUI app developers can just go with a default system that the C code takes care of? I’ve seen ‘autosave’ come up as a topic for mobile apps where the phone can be powered-off or app force-closed at any time.
  6. Some kind of plugin system that allows the RemGlk JSON to pass through various outside executable processes. Profanity filter. Language translation. Screen reader (visual impairment). Macro expansion (“replace {AAAA} with paragraph of text…”). This code would be responsible for stop and start of various plugin apps that could intercept the stdin/stdout stream of JSON coming out of RemGlk. Also support daisy-chaining of plugins (profanity before translation).

The goal of all this is to allow multiple GUI front-ends to have a common code base. And stick with RemGlk’s methods of arg parameters and JSON messages.

A name like “terpmanager” comes to mind, but anything goes. What I’m really asking for is portable C code that can compile anywhere like RemGlk itself. We need some C programmers with time and labor, and same license as RemGlk.

#2

Very interesting.
I thought Garglk / Gargoyle had pretty most of the code implemented and then I realized that is glk not remglk.
We might be doing similar jobs here, so, if I’m able to be of any help,tell me

#3

Share what you can. I’ve been sock for the past couple months so I am behind. But I view RemGlk as an ideal middle layer for front-end apps.

#4

Bringing this old post up… have you experienced any error with TADS interpreters?
They seem to not be able to store the save games correctly (I compile nealy all the terps with problems so far except for the TADS2 and TADS3)

#5

I got a workaround: adding -DGLK_ANSI_ONLY to tads.dir/flags.make gets remglk to let me save and restore (in the old fashion, inline) which is good for now