itch.io

%%WGT0{"w":[{"name":"AnswerDark","type":"contraption","size":[417,142],"pos":[47,100],"script":"on click do\n AnswerDark.show:\"none\"\nend","show":"transparent","def":"prototype2","widgets":{"canvas1":{},"button1":{},"button2":{}}}],"d":{"prototype2":{"name":"prototype2","size":[417,142],"margin":[0,0,0,0],"attributes":{"name":[],"label":[],"type":[]},"widgets":{"canvas1":{"type":"canvas","size":[409,135],"pos":[3,3],"locked":1,"animated":1,"show":"transparent","border":0,"image":"%%IMG2AZkAhwD/AP8A/wD/AP8A/wB0Af8Bgi4ELQEsAQAQAQEt/y2KAA4BAS0CLv8uhy0CLAEADAEBLQIu/y6JLQIsAQAKAQEtAi7/LostAiwBAAkBAS0BLv8ujS0CLAEABwEBLv8ujy0CLgEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BLgEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEuAQH/AY8uAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/LjInSC4VLQEBAQAHAQEtAS7/LjEnSS0BLhQtAQEBAAcBAS0BLv8uLydOLhItAQEBAAcBAS0BLv8uLidPLQEuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ1AuES0BAQEABwEBLQEu/y4uJ04tAi4RLQEBAQAHAQEtAS7/Li8nTS0BLhItAQEBAAcBAS0BLv8uMCdLLhQtAQEBAAcBAS0BLv8uMidILhUtAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcBAS0BLv8ujy0BAQEABwEBLQEu/y6PLQEBAQAHAQEtAS7/Lo8tAQEBAAcuAS0BLv8ujy0BLgEABy4BLQEu/y6RAActAi7/LpAtAQAIAQEtAS7/Lo0tAQEBAAktAS4BLQEu/y6NLQEACi4CLQEu/y6MAAstAS4CLQIu/y6JLQEADC0BLgItAi7/LoQtAS4CLQEADy4BAQEuAS3/LYIuAgEBLgEAEy0BLgEBBC7/LnwBAS4BLQEA/wCk","scale":1},"button1":{"type":"button","size":[377,50],"pos":[16,41],"show":"invert","text":"This Here Is Some Long Text","style":"invisible"},"button2":{"type":"button","size":[82,22],"pos":[309,96],"script":"on click do\n AnswerDark.show:\"none\"\nend","show":"transparent","text":"OK"}}}}}

Ah Richmond has arrived!
I must say that the rationale to Decker's design has grown on me quite a bit (but I already like retro computing stuff, and particularly ancient mac OS).  Deckers only dependency is a sliver of SDL framework so it should be trivial to compile it from make file even on BeOS (Richmond likes that). With a little bit of jumping through hoops you can actually get some cool stuff happening. There is color, but only palettes of 16 color (16 at a time, editable and scriptable so you can use it for some pseudo animations), or, if I understand correctly, 256 shades of grey . You could use it to make 'standalone apps' and you can build custom widgets:

Nice! This helps a lot as you can do like duotones, tritones, sepiatone sets and such.
This is a deck global color set, correct? A card, or per canvas widget property would even more helpful.

Is there a way to hide my widget/contraption invisible as a group? That way the can appear on a card only when called for? 

Also this Decker objects format, that starts some Decker clipboard data such as "%%WDG ..." or whatever, it looks like base64 encoded binary data like a Data URL?  I want to be able to decode these into human viewable formats and then reencoded them when done.

"%%IMG2AIkAZAACAYUAAwEBDYUBAQABAQENhwE ...

Thanks!

And if anyone is using LiveCode or OpenXTalk IDE to mess around with Decker here's script for converting an image control contents to another image control with the required Mac II color palette:

on mouseUp
    export image "Original" to myVariable as gif with palette getDeckerMacIIPalette()
    --  set the text of another image control to myVariable to preview:
    set the text of image "16ColorVersion" to myVariable
    --  then you can save the new gif to a file with:
    --  where tFileName is a file path you provide must provide --
    --  open file tFileName for binary write;write myVariable to file tFileName;close file tFileName
end mouseUp
function getDeckerMacIIPalette
    get "255,255,255" & cr & \
   "255,255,0" & cr & \
   "255,101,0" & cr & \
   "220,0,0" & cr & \
   "255,0,151" & cr & \
   "54,0,151" & cr & \
   "0,0,202" & cr & \
   "0,151,255" & cr & \
   "0,168,0" & cr & \
   "0,101,0" & cr & \
   "101,54,0" & cr & \
   "151,101,54" & cr & \
   "185,185,185" & cr & \
   "134,134,134" & cr & \
   "69,69,69" & cr & \
   "0,0,0"
    -- the sorting of this list effects the resulting image
    sort it numeric by item 1 of each 
    return it
end getDeckerMacIIPalette

Played around with 16 color images a little more, it's more frustrating than trying to make GIFs for a website in 1993, gifs have bigger color palettes and you could adapt the color table based on the original image. But this is restricted to only the 16 colors from 1987 Mac II, which here is a list of the RGB values of the Mac II system palette anyone is interested:
0,0,202
0,151,255
0,168,0
0,101,0
0,0,0
54,0,151
69,69,69
101,54,0
134,134,134
151,101,54
185,185,185
220,0,0
255,255,255
255,255,0
255,101,0
255,0,151

Yeah it is! 
Tinkering around with Apples NSNamed Images I found that modern macOS still includes icons from when Mac OS (OS X) was NeXT step, including the NeXT logo, gave me a little Easter-Egg finding chuckle.

I'm probably going to make a little alternative IDE for Decker as an OpenXTalk stack, and by that I mean I already started.
On mac,win,linux platforms OXT can call out to shell commands for stuff like imageMagick and ffmpeg.
It can also use embedded web ImageMagick (WASM) port to do image manipulation inside a Browser View Widget.
If running on macOS, OXT additionally has a wrapper library for some NSImage stuff with CoreImage filtering.
If nothing else it could expedite or offer fine controls for the lossy conversion to lookup palette images. 

Having Decker running in a browser view allows for tinkering around with the Decker html payload and then reloading it to test any modifications.

Also due to OpenXTalk having its roots in a Hyper-clone called MetaCard that dates  back to the early 1990s on Unix boxes, it also contains (still) a bunches of 16bit icon assets, as well as a set of 1-bit HC icons that a community member converted (I also made some SVG Path string versions of a few of those),  could add to the whole retro-ness.

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

LiveCode script (and the GPLv3 community fork OpenXTalk) has arrays which can be considerably faster then using comma-seperated-values for  text container 'lists' (but when I do I use tab as a delimiter).
Also LC / OXT has a second language, the Extension Builder lang for making 'Widgets' and wrapping external code libraries, which does have an actual List type where the ordered elements can be of any type, Text, Numbers, JSON, Java, or C and ObjC types, Pointers, etc.

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.

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.