As somebody coming from a Python background, it’s taking me a while to adjust to making the most use of Decker’s strengths. So far, I’ve found the “Cards are Workbenches” to be the most empowering thing - where in Python I might write a suite of unit-tests, in Decker I can drop down some sliders and a canvas, wire them up, and see the thing I’m working on updating at 60fps. And once I’ve gotten the thing to work the way I want, other cards can just read the values of those sliders.
I discovered a bunch of things from that post, including:
- making a button transparent, and then drawing a custom icon behind it
- there’s a navigation history so that
go["Back"]always does the right thing - the correspondence between
foo.keyandfoo["key"]is not just for dicts (as in JavaScript) but you can also docard.event.resetinstead ofcard.event["reset"]to invoke an event handler - I had thought about “cards as objects”, but didn’t realise it could be so ergonomic to use them that way; the link between cards and contraptions seems even stronger
Thanks for writing it!