Comparing Mine and John Earnest's Radio Buttons for Decker

Before I move to designing and building a Meta-Machine Code targeting in Decker, I'd like to improve
my previous deck; I should also practice making contraptions by starting with one simple.  I want to
allow for more than a three-by-three pattern, but an unbounded number is foolhardy; permitting four-
by-four and five-by-five patterns is reasonable, however.  A radio button, that kind of button which
allows for only one from a set of buttons to be pressed at a time, provides a good interface to such
and makes for an easy initial contraption.  After working on mine, then searching Decker's forum for
an answer to a peculiarity I've encountered, I noticed John Earnest has also made a radio button.  I
learned a lot about Decker playing around so, particularly in recognizing the kinds of designs which
Decker prefers, but also just getting better at using it; I provide an unimpressive deck using ours.

That simplest form of a radio button is a button which merely deactivates the others in its set when
pressed.  This hardly felt like a substantial contraption, and I also figured I could perhaps find a
better way to do it.  I was very wrong.  John Earnest's radio button contraption attaches text and a
group attribute to a button, rather simply; his contraption traverses its containing card for others
in the group and switches any off.  I'd omit the text, but his design is still better than mine.  My
design forces all of the buttons into a single widget, and I first tried to place the button widgets
dynamically; after studying his calender widget in the default deck, which mimics many small buttons
by tracking clicks' coordinates, my design works likewise and omits buttons internally for a canvas.

I feel silly for first screenshotting Decker's interface and importing it into Gimp to get a button,
but I scrapped those graphics and got better with Decker's very nice drawing tools instead; I made a
perfect pair of graphics after rereading relevant sections of the very nice documentation by chance.

My design uses the margin system to create a repeating button pattern, and the view function reduces
the contraption's size to cull any incomplete buttons; my script for the contraption is very simple:

 size:20
 dimensions:(size,size)

 on get_value do
  floor button.pos/size
 end

 on set_value x do
  button.size:dimensions
  button.pos:me.size&size*(0,0)|x
 end

 on view do
  me.size:size*floor (dimensions|me.size)/size
 end

The all-encompassing canvas has a similarly simple script which checks the click and makes an event:

 on click pos do
  set_value[floor pos/size]
  card.event["click" get_value[]]
 end

After inspecting John's contraption, which I was able to paste into a deck effortlessly, I made mine
too obey locking by the following changes; the colour mapping was taken directly from John's script:

 unlocked:image["%%IMG2ABQAFABXAQYADQEIAAsBCgAJAQwACAEMAAgBDAAIAQwACAEMAAgBDAAJAQoACwEIAA0BBgBX"]

 on view do
  button.paste[unlocked]
  if card.locked button.paste[unlocked.copy[].map[1 dict 13]] end
  me.size:size*floor (dimensions|me.size)/size
 end

 on click pos do
  if !card.locked
   set_value[floor pos/size]
   card.event["click" get_value[]]
  end
 end

Unfortunately, my radio button, almost usable, for some reason loses its state whenever the listener
is entered.  The only state is the internal position of a widget that changes to indicate the active
button.  I tried to store its state elsewhere by having both canvases cover the contraption instead,
but it continued to reset.  I don't believe myself to have been making an error with volatility here
and suppose I should avoid such state from now on.  I may bug John about this to update the article.

My radio button returns the pressed button's coordinates in a click event, whereas John's are normal
buttons in comparison.  John's contraption uses attributes to make it easy to create a group without
any code; mine also requires no code there, but his is still better.  This exercise had me recalling
a principle behind widgets: It's best always to provide attributes instead of forcing someone to use
code.  I've been distracted by how Decker removes what I find distasteful, but I should carry it on.

The improved pattern producing deck won't use this radio button contraption, but maybe the graphics.
.