I'm just reading through those 'responses to responses', which helped me understand the parameters you've set for Decker targeting embedded or extremely limited and older devices, a noble goal IMO! It then makes more sense to then limit to 16 color palette and 8bit sound samples, but it's still rather harsh constraints by todays standards, maybe even by 1990s standards. I think that limits the possibilities for creativity and may turn off some potential users.
However, THIS is exciting:
"If you know C, it’s fairly straightforward to glue custom functionality into Decker that calls native libraries. Likewise, if you know JavaScript, you could choose to hack up web-decker to expose browser APIs that aren’t normally available to Lil, like the Gamepad API or the ability to perform an XMLHttpRequest. There are lots of inherently “non-portable” features I don’t intend to add to mainline Decker which a given user might still want for a project, and letting them easily add things themselves is what open source is all about. The current version of web-decker is intentionally built without “minification” and doesn’t require anything more than a text editor to make this kind of modification. If it was shipped as an opaque wad of WASM bytecode a whole range of casual tinkering would be off the table and gated behind a complex build process and mandatory tooling."
I may just try my hand at hacking around with a non-mainline Decker, HTML5 APIs access could be a game changer, then one can call whatever WASM compiled modules. And we can still pack that all up in an Electron app wrapper if we want to. Now I'm wondering if Decker 'Canvas' could be web canvas element, then it could be passed to external (JS) code to draw whatever into it.
And If we could just getting that interpreter to ignore a 'the' token I think that would add just a tad more xTalkishness.
One thing that might be helpful with macOS app version would be to have certain keys in it's info.plist so that it asks permission to use the microphone on newer, more locked down versions of macOS.
Also, when I map .deck files to Decker and then double-click a .deck file in the Finder, Decker opens it in its resource (Font/Res) mover dialog, instead of just opening the clicked Deck file normally.
For anyone that IS still looking to convert ancient HyperCard stacks to Decker decks (or any other format), there exists tools like StackImport (CLI) or HyperCardPreview.app, that can convert HC Stacks to JSON and PNG Images representation of a .stack/parts props/backgrounds/Text/Scripts, which should be very helpful compared to straight parsing a .stack (I believe stack used a RIFF like structure). Also, believe it or not, there are still tools that can read a resource fork (or maybe it's actually the contents of the ._AppleDouble version of a ResFork?) that work on the very latest iterations of macOS (I've tested them myself on 11 BigSur).