Post by OXTPaul in How you can help Decker

Viewing post in How you can help Decker

This is an excellent modern homage to HyperCard. Graphically at least, it's emulated Mac System 6!
But it also has some very interesting differences, and it's own flavor of xTalk.
This could be a great general purpose app engine with some work and...
Maybe some letting go of the strictly-retro style which I understand is meant as a features. Like when user imports a picture it makes a 1-bit version of the image (Atchinson dithered?), but why not support color images? Why restrict it to things that made HyperCard annoyingly outdated looking back when Apple / Claris / Apple was still neglected it?
And how about some more of that sweet sweet syntactical sugar instead of just a lil? :)
And HyperCard playSentence music notation (or something better)? Perhaps I'll try to port the library I'm using for that. I see there is a sound function that can generate PCM samples, so there's at least sine-wave pitches, and a non-blocking Play sound command. I may try to port my piano widget if I can squeeze in the time,

I'm currently trying to revise and maintain a fork of the GPLv3 xTalk LiveCode Community Edition from LiveCode Ltd., perhaps the most viable commercial xTalk still in business (SuperCard seems dead, Toolbook is dead, etc. in a long line of them... anyone remember Oracle MediaTalk? ). Our community fork is renamed OpenXTalk, it's on GitHub along with lots of extensions to it that I worked on in my personal repos.

The goal of OpenXTalk.org, however is to endeavor to promote, examine, talk smack about, ANY and all xTalk interpreters that are still alive and kicking, specifically open-source xTalks such as Decker and there's a few others out there that are quite nice efforts. It would be excellent to cross-support each others open source efforts, the inspiration is the same. It feels like there should be more of an xTalk ecosystem or community the way there is still seems to be for Pascal, BASIC, Python, Lua, etc. And XTalk might just be the perfect sort of scripting for use with todays language model AIs that are already parsing natural language instructions and spit out code (I've used it to help wrap some Apple APIs), so I think this may be xTalk-type languages time to shine, and hopefully grow.

Internet Janitor1 year ago

Lil is not intended as a flavor of xTalk; it is its own programming language. As I note in the language manual it is primarily influenced by Lua and Q. I feel that a small, expressive language is easier to learn than a large, verbose language with a great deal of case-specific syntactic sugar, and that a functional, expression-oriented structure is more flexible than a statement-oriented structure.

Decker has a number of intentional limitations which I feel produce interesting creative constraints, which give it a unique texture and flavor, and which in some cases aid in providing pixel-perfect cross-platform consistency. I have written rationale for some of these design decisions here.

Decker does support color images; it uses a configurable 16-color palette. This thread details how to import color images. There are a wide variety of ways a user might wish to adapt a particular image to a 16-color palette, so in the interest of simplicity I make no attempt at an exhaustive suite of knobs and buttons. Web-Decker embeds the entire editing environment into freestanding, self-executing documents, and every feature must be carefully weighed against its cost in the form of that runtime stub's size. For the same reason, Decker avoids reliance on external libraries wherever possible; even if a third-party C library might be helpful in some situation it would invariably need to be ported to and maintained as JS as well (or vice versa).

As you observe, it is currently possible to generate and play sound on the fly, so an enterprising user could indeed furnish something resembling HyperTalk's "music notation" as a Lil module. See also Millie's JankyTunes contraption and other musical experiments. A built-in sequenced music playback mechanism based on a subset of the Amiga Module format is planned for the future.

I do not wish to have any involvement with LLM-based technology.

OXTPaul1 year ago (2 edits)

Thanks for the fast and thorough response.
Never heard of Q lang (will look into it), but I've spent some time with Lua and that's pretty OK.
While 'Lil' may not be intended to be xTalk-like lang it comes close to reading like one... maybe that's an unavoidable consequence of implementing an HC-like event driven environment? Its close enough for me and has the Deck(Stack)/Card metaphor. I like it. It seem\ to have at least a subset of xTalk, but it also has list and dictionary data types, custom control widgets / contraptions, and more modern features, so that's super useful!

xTalk has the transient 'It' variable and 'The' (which is largely ignored by interpreter) which can go a long way towards making scripts read more like a natural language sentence. Being English like helps English speaking people, even very young people, learn the language fast, I know some ECL educators that will swear that xTalk is the best thing for teaching basic concepts. It is certainly what got me hooked as a kid. I also have a theory that straight readability reduces the need for as many code comments. HyperCard 2.0 had some JIT precompiling that helped speed things up, but these days it seems CPUs are fast enough to handle any extra bit of interpretation without much slowdown.

" C library might be helpful in some situation it would invariably need to be ported to and maintained as JS as well (or vice versa)"
There is the possibility of there being already ported / WASM compiled, small versions of various libraries (ImageMagick for example), but I do understand that you want/need to keep its engine small and as self-contained as possible. But then it also seems a bit pointless to maintain a Desktop app/exe versions at all, since it is still subjected to the same limitations as running sandboxed in a browser.

I think you should at least consider using 'native' file APIs for file stuff. It seems like more work to implement a System 6 file dialog from scratch then to just call out to the OS or HTML5 api. Bug report: in the built in file dialog there's no obvious way to go back up to a parent directory, Command+ArrowUp didn't work, and there's also no way to access my computers other disk partitions.

IMO one of the main things that made HC so insanely great was its extensibility with XCMDs/XFCNs. While HC couldn't play tracker formats like .s3m, .mod etc. there was an External that could enabled it. I even built MIDI librarian 'app' with HyperMIDI Xternals that could talk to my ancient Yamaha external synth modules back in to day. Lots of stuff most never would have thought you could do with HC. And HC had early polyglot coding, you could mix in AppleScript ( or any other OSA script language), via 'do feild "AppleSciptContainer"as AppleScript' syntax (which later would mean Shell commands too). If your main target is web/html5 then I think it would be great to be able to tap into JS/ HTML5 APIs (and maybe Node for the desktop version) when the need arises.

Anyway is great fun to play around with, really nice work so far!

I'll have to spend some time checking out your source later.

I also checked out your web comic. Nice, the art reminded me a bit of Cerebus the Aardvark.

OXTPaul1 year ago (1 edit)

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).

itch.io

Viewing post in How you can help Decker