Decker v1.20 is a maintenance release, including numerous bugfixes and some enhancements to the Lil scripting language.

Fixes (Web):

• Pressing "0" on the touch keyboard no longer highlights the "dead keys" on either side of the spacebar.
• Corrected a possible crash when invoking the listener from the script editor when the current script contains a syntax error.
• Corrected problems related to importing GIF images without using read[].

Fixes (Web and Native):

• It is no longer possible to drag and drop images onto a locked deck.
• Pasting an image from the clipboard no longer applies the "scale to less than 75% of screen dimensions" rule applied to importing images.
• Corrected "ghosts" from the line tool when entering or exiting FatBits mode.

New Features:

• The Lil "@" operator now permits primitive operators as left arguments, for consistency with its behavior when the left argument is a function. The following are equivalent:

 each x in "Apple","Banana","Cherry" first x end
("A","B","C")
 (on _ x do first x end) @ "Apple","Banana","Cherry"
("A","B","C")
 first @ "Apple","Banana","Cherry"
("A","B","C")

• Previously, the "x.event[]" function exposed by the Deck, Card, and Widget interfaces always returned "x"- the originating interface. This has been redesigned to instead return the result of the invoked function (or 0, if no such function exists).

For example, if a button "Abilene" contains the script:

on click do
 2+3
end

Invoking it like

Abilene.event["click"]

Will return 5. This behavior is especially useful within Contraptions: a prototype script can invoke user-supplied event handlers that compute or retrieve information about the contraption instance's context. While this is a breaking change, it is unlikely to disturb existing programs.

• There is an additional breaking change in the behavior of the "range" operator. Previously, the "range" of a dictionary would yield the keys of said dictionary. This is a useful operation, but this choice of overload is confusing. Mathematically, a dictionary is analogous to a function which associates a set of keys (inputs) with a set of outputs- thus Lil's unified bracket notation for indexing data structures and invoking functions. In standard terminology we would refer to the inputs to a function as its "domain" and the outputs as the "range". Thus, the name of the operator suggested behavior that is the opposite of what it actually did!

The solution comes in two parts. Firstly, "range" of a non-integer x is redefined as the elements of the dictionary interpretation of x (which is an identity operation for lists):

 range ("Apple","Banana","Cherry")
("Apple","Banana","Cherry")
 range ("Apple","Banana","Cherry") dict 11,22,33
(11,22,33)

We then introduce a new unary operator "keys", which provides the keys of the dictionary interpretation of x:

 keys ("Apple","Banana","Cherry")
(0,1,2)
 keys ("Apple","Banana","Cherry") dict 11,22,33
("Apple","Banana","Cherry")

In both cases, the result will always be a list. Having the ability to extract both keys and elements without a loop produces pleasant symmetry with the "dict" operator. This change to "range" may break some existing scripts, which is unfortunate, but after careful consideration I feel this revised design is much clearer and less surprising. Fortunately, impacted users need only substitute "keys" for "range" as needed, and in some cases programs become noticeably more direct and concise.