Depending on what you're trying to do, either a combination of ! and = (for a scalar boolean value, logical XOR is the same as "not equal to") or possibly bits.xor[].

Ok forgive me, I didn’t follow your operation faithfully, I now see. Your method was to use a button to point at one field that itself pointed at another field (which contained the rt formatted text).  I was skipping the middle-person field and apparently, by doing that, it doesn’t render the rt formatting.  I’m leaving this post because it may come up in the future; perhaps IG (or someone else) could simply verify that this was indeed my problem and if anything maybe propose how I might’ve skipped the middle-person step and kept the RT formatting.

It's totally fine to be new and have questions! Decker is a pretty friendly environment to try things and figure them out. And I think most of the things that look like videos in the thread are actually gifs. I know I use a screen-to-gif recorder when I need to make a small example of something.

Okay, I think these are your main questions:

1) How can I make Decker use the whole list of widgets I defined earlier?

You just need a tiny change to how you're referencing them. You need two periods, instead of just one in this case.

fields..show:"none"

2) How can I make my !alert use my rich text formatting?

In-line commands run by dialogizer don't carry over any of the rich text features. I'm pretty sure they're just run as code.

However, you can point to another field's value inside of your !alert[] in the same way you point to source.value inside of dd.say[].

!alert[problem.value]

I know it's another step, and another thing to have to manage while you're editing but it should be pretty straightforward. 

Another thing that I think might help you sometimes is the ScriptViewer contraption. You can have it display the card script and let your edit it from your card in interact mode instead of having to use a workaround with eval. And because the ScriptViewer only displays scripts that exist elsewhere you can safely delete the ScriptViewer contraption when you're done.

Just another possibility, in case it helps!

As a general rule, web applications are not allowed to start playing sound without user interaction. Web-Decker attempts to start its audio subsystem when the user first clicks or types on the keyboard. It's possible there's some additional inconsistency in behavior, but what you're describing sounds to me like normal webapp sandboxing constraints.

Lil doesn't have a per se list literal syntax. Your example is one straightforward way of making nested lists:

(list 0,1),(list 2,3)

Another fairly general way of declaring static data is to use "parse" on a string of JSON/LOVE:

"%J" parse "[[1,2,3],[4,5],[6,7,8,9]]"
# ((1,2,3),(4,5),(6,7,8,9))

Within Decker it's often a good idea to store lengthy static data in a Field widget (where it can be encoded/decoded to/from LOVE via the .data attribute), or as a table stored in a Grid widget, where it can be viewed and directly manipulated. Modules (Lil libraries for Decker) don't have direct access to a deck, so they have a dedicated mechanism called a KeyStore.

If the sublists are of equal size, you could turn a flat list into a nested one using a primitive like "window":

2 window range 6
# ((0,1),(2,3),(4,5))

You could also construct a nested list piecemeal by index in a named variable:

a[0]:1,2,3
a[1]:4,5
a
# ((1,2,3),(4,5))

This last approach is particularly handy for nested dictionaries; see the code examples in the reference manual entry for the Array Interface.

Does any of that help?

Also, how can I implement a "whitelist" for the "Overlaps", that draws off a canvases' name/textual content?

The script on the “Make Magnet” button just creates a new Canvas widget and adds it to the card. You can set or retrieve the script of a widget with the .script attribute. So:

mycanvas.script:"on click do alert[\"boo\"] end"

Alternatively, when a widget doesn’t have a handler for a particular event, that event bubbles up to the card, then the deck. If you want a bunch of widgets that all have the same behaviour, you can put the on click ... end handler in the card, and not have to worry about adding it to each widget individually.

The simplest way to perform ciphering would be to use a dictionary. We can make a dictionary that maps characters to other characters like so:

rot13: "abcdefghijklmnopqrstuvwxyz" dict "nopqrstuvwxyzabcdefghijklm"

Given a string, we can use each character to index into our dictionary with the "@" operator:

rot13 @ "something else"
# ("f","b","z","r","g","u","v","a","t",nil,"r","y","f","r")

For characters like spaces, which aren't defined in the rot13 dictionary, we get a nil. As a catchall, we can use "fill" to substitute a generic replacement for all nils:

" " fill rot13 @ "something else"
# ("f","b","z","r","g","u","v","a","t"," ","r","y","f","r")

And if we wanted to collapse that sequence of characters into a flat string, we can use "fuse". Note that this step isn't necessary if we're stashing the result in a field's .text attribute; it implicitly fuses lists of strings as a convenience:

"" fuse " " fill rot13 @ "something else"
# "fbzrguvat ryfr"

Putting that all together, given fields "input" and "output", give "input" a change[] handler:

on change do
 rot13: "abcdefghijklmnopqrstuvwxyz" dict "nopqrstuvwxyzabcdefghijklm"
 output.text:" " fill rot13 @ input.text
end

And now we have a (crude) rot13 translator. It would probably be much more useful if we preserved all the non-alphabetic characters intact instead of turning them all into spaces. We can be a little fancier about how we construct the translation dictionary and address this:

on change do
 a1:"abcdefghijklmnopqrstuvwxyz"
 a2:"nopqrstuvwxyzabcdefghijklm"
 A1:"%u" format a1
 A2:"%u" format a2
 chars:"%a" format list range 256
 rot13:(chars dict chars),(a1 dict a2),(A1 dict A2)
 output.text:rot13 @ input.text
end

If you want to do a translation based on fixed-size bigrams or trigrams, or something along those lines, "window" might be useful:

2 window "SomeWords!"
#("So","me","Wo","rd","s!")

And you can use "drop" to exclude characters you wish to ignore (or conversely, "take" to retain only characters you care about):

(" ","!") drop "Some Words!"
# ("S","o","m","e","W","o","r","d","s")

For even fancier find-and-replace scenarios you could use RText.replace[]. Note that this returns a rich-text table and should be assigned to the .value attribute of a field, rather than .text, or converted into a string with rtext.string[].

rtext.replace["some text" ("me","ex") ("you","post")]
# +----------------+------+-----+-----+
# | text           | font | arg | pat |
# +----------------+------+-----+-----+
# | "soyou tpostt" | ""   | ""  | 1   |
# +----------------+------+-----+-----+
rtext.string[rtext.replace["some text" ("me","ex") ("you","post")]]
# "soyou tpostt"

Does any of that help?

When the arrow keys are pressed, a navigate[] event is sent to the current card with an argument of "up", "down", "left", or "right". If you wanted to make these events move a canvas, you might have an event handler in the card-level script something like

on navigate dir do
 deltas:("up","down","left","right") dict ((list 0,-1),(list 0,1),(list -1,0),(list 1,0))
 myCanvas.pos:myCanvas.pos+deltas[dir]*32
end

If you wanted that canvas to trigger "exits" when it matches certain positions, you could mark them with buttons (perhaps set to "Show None") and then send them a "click" event on an overlap; the buttons could in turn go[] to other cards, trigger alert boxes, etc.

on navigate dir do
 deltas:("up","down","left","right") dict ((list 0,-1),(list 0,1),(list -1,0),(list 1,0))
 myBug.pos:myBug.pos+deltas[dir]*32
 each button in extract value where value..type="button" from card.widgets
  if button.pos~myBug.pos button.event["click"] end
 end
end

For a fully-worked example of a game that uses arrow keys for tile-based movement, you should take a look at Decker Sokoban.

Confirmed; Keystores were not properly serializing raw lists. I've patched the issue in the source repo.

Dictionaries, tables, and strings do not exhibit this problem, so any can be used as a workaround.

The "+" operator in Lil is exclusively for addition. It will coerce strings into numbers in a best-effort fashion, which is why you're getting zero:

"5"+3               # 8
" 2.3" + "1Hello"   # 3.3
0+"Hello"           # 0

The "fuse" operator is binary; it expects a left string argument to intercalate between elements of a right list argument:

":" fuse "A","B","C"   # "A:B:C"
"" fuse "A","B","C"    # "ABC"

Assigning a list to a field's ".text" attribute will implicitly concatenate the elements of a list together, as a convenience. The following are equivalent:

hellotext.text:"" fuse "Hi","There"
hellotext.text:        "Hi","There"

Cards are normally in scope by name, so you don't typically need a fully-qualified path to reach a widget on another card. The following will be equivalent from a card/widget level script:

deck.cards.A.widgets.name.text
           A.widgets.name.text

Does that help?

If you aren't already, I strongly recommend using The Listener to try expressions out piece-by-piece as you develop.

You left Decker running for 24.8 days?

EDIT: Wait, no, I see what’s going on.

Native Decker computes sys.ms as a float, Web Decker takes a float from the browser and truncates it into a 32-bit integer.

I guess it shouldn’t matter if you’re using sys.ms for performance timing (duration:sys.ms - start) but it does make problems if you’re trying to divide the clock with a modulus operator.

It's a perfectly reasonable question!

The binary "in" operator can- among other things- check for the presence of a substring in a larger string:

"beef" in "ham & beef"      # 1
"apple" in "ham & beef"     # 0

If the left argument is a list of strings, you'll get back a list of 1s or 0s indicating whether each substring was found:

("beef","ham","apple") in "ham & beef"   # (1,1,0)

If you're just asking whether "any" word is found, you can take the "max" (maximum) of the result:

max ("beef","ham","apple") in "ham & beef"   # 1
max ("bone","apple","tea") in "ham & beef"   # 0

Note that all these comparisons are case-sensitive! If you want a case-insensitive comparison, the easiest way is to lowercase the string you're searching and make sure all your substrings are already lowercase:

("beef","ham","apple") in "%l" format "Ham & BEEF"   # (1,1,0)

Does that make sense?

For other kinds of string-searching you might want to consult the Lil reference manual on the "like" operator (which performs glob-matching with * wildcards) and the Decker reference manual on the "rtext.find[]" or "rtext.replace[]" utility functions, which retrieve the index of found words or perform substitutions, respectively. Everything in the "rtext" interface will work on a plain string, too.

Hmm. I can tinker with the internals of image.rotate[] to try to make it better behaved. When you need exact 90 degree rotation increments, image.transform[] is more efficient, and will always be precise. Here's a routine you could use as a workaround for now:

on rotated img steps do
 # modify 'img' in-place based on 45 degree steps:
 if     steps~0 # do nothing
 elseif steps~2 img.transform["right"]
 elseif steps~4 img.transform["right"].transform["right"]
 elseif steps~6 img.transform["left"]
 else           img.rotate[steps*pi/4]
 end
 img
end

When a row or cell of a grid widget is clicked, it is sent a click[] event with the active row as an argument. See Events in the Decker reference manual.

on click row do
 if row~0
  alert["you clicked the first one"]
 elseif row~1
  alert["you clicked the second one"]
 else
  alert["you clicked something else"]
 end
end

When the distinction between a number and a string matters, the simplest way to convert the string into a number is with an arithmetic identity operation, like adding zero, as in your last example.

The format operator is for converting data into strings (or lists of strings); its counterpart for decomposing strings into other values is "parse":

 "%i" parse "123"
123
 "%i|%i|%i" parse "123|34|89"
(123,34,89)

If I understand correctly, you should be able to do this more straightforwardly with

if grid.value[idx]
 # ...
end

Indexing a table with a number fetches the corresponding row of the table as a dictionary, which will be "truthy" so long as the table has at least one column. If the row does not exist, indexing in this manner will result in nil, which is a "falsey" value:

t:insert a b with 11 22 33 44 55 66 end 
# +----+----+
# | a  | b  |
# +----+----+
# | 11 | 22 |
# | 33 | 44 |
# | 55 | 66 |
# +----+----+
t[2]
# {"a":55,"b":66}
t[-1]~nil
# 1
t[3]~nil
# 1

Another approach would be to use the "count" operator to determine the number of rows in the table, and compare that to "idx":

count t
# 3

Does that help at all?

"#" is not a valid Lil identifier; it is used in Lil scripts to indicate a comment, which ignores the remainder of the line. Lil identifiers are described in the Lil Reference Manual as follows:

Variable and function names may contain any alphanumeric characters (as well as ? and _), but must not start with a digit. 

If you give a widget a name which is not a valid identifier, it will not be automatically available as a local variable, but it can be accessed by name from the card's ".widgets" dictionary:

card.widgets["#"]

Your description of what you're trying to do is inconsistent and unclear. If the idea is to- for example- index into images stored in a rich-text field named Y and paste the image corresponding to the value of the slider ("me") onto a canvas named X, you could use something like:

on change val do
 X.paste[Y.images[val]]
end

I think you need to send the event to slider1 in a slightly different way:

slider1.event["change" val]

There's another post on the forums explaining more here.

And you'll also need to define what val is in this context. That could be in either script.

For now I put both changes in button script:

on click do
 slider1.value:slider1.value - 1
 val: slider1.value
 slider1.event["change" val]
end

That's a rather expansive question!

Exporting GIF images with write[] and asking users to convert them to other image formats as desired will generally be the simplest approach. Decker natively supports GIF because it's a simple and universally-supported format that is also a good match for Decker's paletted-color model.

If you decide to dig deeper, the image interface has a .pixels attribute which, when read, will give you the pixel values of that image as a list of lists of numbers (a matrix).

These numbers will be Decker pattern indices, so you'd need to do some work to "flatten out" 1-bit patterns and animated patterns (if applicable) and then look up the corresponding RGB colors from Decker's active palette. The internals of the PDF module might be a useful reference.

In principle, you could use an Array interface to construct your own PNG encoder in pure Lil, but this could be a significant amount of work! The CUR format is a bit simpler than PNG and (so far as I'm aware) builds on BMP, which is also relatively straightforward. An encoder is, at least, quite a bit simpler than a decoder, since you can avoid implementing all the features and options you don't need for your intended application.

If you only care about PNG export from web builds of your tools, you could also consider writing a module that uses the danger zone to call some JavaScript from Lil and use ordinary web APIs to perform the conversion. See The Forbidden Library for examples of doing this kind of JS/Lil interop.

Does any of that point you in the right direction?