Widgets have an attribute called "show" which controls their visibility; this can be "solid" (the default), "invert" (an alternate color-scheme), "transparent", or "none".

Suppose the button X is on card C1 and the button Y is on card C2.

You could give X a script for toggling Y's visibility:

on click do
 C2.widgets.Y.toggle["solid"]
end

Or a simpler version that just makes Y visible:

on click do
 C2.widgets.Y.show:"solid"
end

There are several other examples of doing this sort of thing in this thread.

To make clicking a button "unlock" dialogue or behavior elsewhere in the deck, you'll need to remember that the button has been clicked, and consult that record at a later time.

Checkboxes are just a special visual appearance for a button, so every button widget has a "value" attribute that can store a single boolean (0 or 1) value. Thus, we can use the button itself to keep track of whether it's been clicked. Suppose you've given the button Z on card C1 a script like so:

on click do
 me.value:1
end

A script on another card could reset Z's value,

C1.widgets.Z.value:0

Or test its value in a conditional:

if C1.widgets.Z.value
  # do something special
end

If you have lots of "flags" like this, it may be a good idea to centralize them in some kind of "backstage" card so you can keep track of them easily, and perhaps to give yourself a script for resetting the state of the deck.

Does that make sense?

You can find documentation for format strings in Lil, The Formatting Language.

The format string of a slider widget is only given its value, which would usually be displayed as an integer (%i) or a floating-point number (%f); the rest of the string could, for example, provide units, like "%f degrees". In this way you *could* hardcode a maximum into the format string, like "%i/20" for an integer between 1 and 20 to be displayed like "7/20".

Extending the current behavior of sliders to make min/max and possibly other attributes of the widget available for formatting could be an interesting feature; I'll mull it over. For now, including that sort of information would require scripting. If you need this functionality in more than one place, perhaps you could use The Enum Contraption as a starting point?

When you open the "Action..." dialog, Decker will attempt to "unpack" any script already attached to the button and reflect it in the settings you see in that dialog, and when you confirm it writes an entirely new script. This dialog exists purely as a convenience for composing simple scripts without writing code, and is not intended to manipulate or append to arbitrary user-generated scripts.

Hi, I'm not IJ but I did some experimentation and I think I've figured it out - it seems the card.copy and card.paste commands let you copy multiple widgets at once.

So you'd do like this:

card.paste[A.copy[A.widgets.X,A.widgets.Y,A.widgets.Z]]

(As a side note, if you're referring to a card in a script you can just use the card's name, you don't need the deck.cards in front of it)

Let me know if this works for you!

The .text attribute of a Field is a string. Performing any sort of arithmetic operation on a string coerces it to a number (as a convenience), and in many places a string like "23" is fully interchangeable with the number 23:

 100+"23"    # 123

Unfortunately, indexing into lists isn't one of those places:

 foo:"Alpha","Beta","Gamma"
 foo[1]      # "Beta"
 foo["1"]    # 0
 foo[0+"1"]  # "Beta"

Part of the reason Lil draws a hard line here is that indexing lists by strings is one way to force them to "promote" to dictionaries when you assign through them; trying to parse strings into numbers could lead to some very nasty ambiguity:

 foo["z"]:"Delta"    # {0:"Alpha",1:"Beta",2:"Gamma","z":"Delta"}

I apologize for the confusion stemming from my suggestions.

One possible alternative would be to make "counter" a Slider widget instead of a Field; The value of a Slider is always a number.

The rect module (which, for those unfamiliar, is included in the "All About Draggable" example deck) includes functions like rect.overlaps[] and rect.inside[] for manipulating "rectangles", which can either be a dictionary containing pairs with the keys "pos" and "size" or any Decker interface value that happens to have those fields- widgets, for example.

The pointer interface has a .pos field, but no .size field. Using an invalid index into an interface type returns 0, so the pointer interface kinda fulfills the contract and sort of works as an argument to these utility functions (as if it were a rectangle of size 0), if only by coincidence/accident.

I whipped up a little test, and sure enough this seems to work fine given an animated button:

on view do
 field1.toggle["solid" rect.inside[pointer button1]]
end

(Note that "tooltips" like this won't work properly on multitouch devices, since such input devices do not update the pointer position while a user's finger happens to be hovering above the display; this is why Decker doesn't have any sort of tooltip functionality built in.)

The same script body ought to work just fine from a centralized event pump rather than having every object with a tooltip be individually animated. I don't really follow what you mean in terms of the rect module "detecting the widget type".

This is working as designed. 256-gray images are not directly displayable within Decker, since Decker's color palette does not contain 256 colors and patterns; only 48:

A grayscale image must be converted into a proper paletted image before it can be displayed; otherwise the grayscale values are effectively randomly mapped to entries in the above table, and any higher indices appear as white. The image.transform["dither"] function is one way to produce a 1-bit dithered image from a 256-gray image, using Bill Atkinson's algorithm. Rescaling a dithered image will considerably reduce its quality. The correct order of operations to prepare a dithered image therefore must be:

1. obtain or otherwise create a 256-gray image.
2. perform any desired palette adjustments to the 256-gray image, like adjusting white/black points or contrast.
3. scale and crop the 256-gray image to the desired final size.
4. dither the 256-gray image, resulting in an image consisting exclusively of patterns 0/1.

From inside a contraption instance, "card" refers to the contraption instance itself; this is handy if you want to send events to the "external" scripts on the contraption or inspect default properties like .locked, .show, or .font.

If you want to refer to the card within which a contraption resides, you can generally use "deck.card". Strictly speaking, "deck.card" is the active card on the deck; the card the user is looking at. This will only be distinct from the contraption's parent card if the contraption is being sent a synthetic event from some external script.

A different angle to consider would be prompting the user for a destination card when importing an image. You could, for example, use alert[] in "choose" mode to select cards from the deck by name, using the current card as a default:

alert["pick a destination card:" "choose" deck.cards deck.card.name]

The downside to the above is that if a user hasn't given cards logical names they're "picking blind", which can be error prone. Every design problem is fractal in nature...

Anything that you want to "remember" across event handlers needs to be stored in a widget. A true/false flag, for example, could be stored in a hidden checkbox. If we had a card named "flags" with a checkbox widget named "hasKey" your scripts might look something like

on click do
 flags.widgets.hasKey.value:1
 go[bednokey]
end
...
on click do
 if flags.widgets.hasKey.value
  go[bednokey "SlideUp"]
 else
  go[bed "SlideUp"]
 end
end

If the widget happens to be on the same card as the script which references it you can shorten paths like "flags.widgets.hasKey.value" to just "hasKey.value".

If you want to show or hide objects on a card, you may find it more flexible to use a transparent Canvas widget containing an image of the key. You can show, hide, or reposition canvases at will, sort of like a sprite object:

myCanvas.show:"solid"
myCanvas.show:"transparent" 
myCanvas.show:"none"
myCanvas.toggle["solid" booleanExpression]
myCanvas.pos:otherWidget.pos

This may also remove the need for a separate "flag" widget; the canvas itself will remember its visibility setting:

if bed.widgets.keyCanvas.show~"none"
 # ...
end

Does that help answer your question? There are lots of other examples of doing this sort of thing in this thread and elsewhere on the forum.

Let's start with some context. All of the contraptions in WigglyKit share the convention of an "animation value"  consisting of a dictionary with the keys "frames" (a list of images) and "order" (a list of integers; indices into the list "frames"). There's nothing intrinsically special about this dictionary; it's just a convention to bundle together all the relevant information for a wiggly animation such that it can be easily moved around between those contraptions and manipulated with scripts.

WigglyKit offers an example of pulling the animation value out of a WigglyCanvas and then saving it as a GIF:

v:wc.value
# (optionally) make the background opaque:
v.frames:v.frames..copy[].map[0 dict 32]
gif.frames:v.frames @ v.order
gif.delays:10
write[gif]

As noted in the Decker reference manual for the built-in function write[] (see note 12), to save an animated GIF we need to call write[] with a dictionary with the keys "frames" (a list of images) and "delays" (a list of integers; how many 100ths of a second should each frame be displayed?)

So really, what we need to do to save a GIF outside the specific context of WigglyKit is make an appropriately-shaped dictionary and hand it to write[]:

gif.frames: ... # obtain or assemble a list of images, somehow
gif.delays: 10  # one number applies the delay to every frame
write[gif]

Obtaining/assembling that list of images will depend entirely upon your use case. We might grab them from a sequence of canvases:

gif.frames: (c1,c2,c3)..copy[]

We could do the above in a more verbose way, if we wanted:

gif.frames: c1.copy[],c2.copy[],c3.copy[]

Or perhaps we could use the recently-added ".images" attribute of rich-text fields to grab all the inline images stored in a field:

gif.frames: myRichTextField.images

Etc.

Does that help point you in the right direction?

Hmm. I think this would be rather tricky.

Decker is designed to try to accommodate text input on devices that don't have a physical keyboard, so it avoids exposing low-level keyboard events and doesn't (presently) allow scripts to modify the contents of a text field while it has user focus. Consider how the soft keyboard overlay introduced in Decker 1.19 interacts with unlocked field widgets.  While it's easy enough to detect that a user has pressed return in a text field (and typed a newline),

on change do
 if "\n" in me.text
  # ...
 end
end

That event handler wouldn't be able to clear out the user's line of input, which would make a scripting REPL or an IF parser input awkward.

I'll give this some serious thought and see if I can come up with a good compromise to allow the sort of thing you're interested in making

Decker 1.49 includes some subtle changes that I think will address this request.

It is now possible to clear a field via scripts while it is selected. In touch mode, this will additionally dismiss the on-screen keyboard and remove focus from the field.

In the above example, the script looks like this:

on change do
 if "\n" in me.text
  log.text:log.text,"\n %s%J" format me.text,list eval[me.text].value
  log.scroll:99999
  me.text:""
 end
end

There are a few details to be aware of when using this technique:

• It takes 1/4 of a second without user input for the contents of a field to fire a change[] event, and it is also possible to fire a change[] event by pasting an arbitrary block of text into a field. Therefore it's possible for a user to type several characters following a newline, or even multiple newlines; input handling code will need to be robust to this.
• An alternative to looking for "\n" in a change[] event would be to use the run[] event, which is fired immediately when the user presses shift+return. This may be less intuitive for users, and therefore unsuitable for many applications, but it's much less error-prone and more flexible than newline-delimited input; the run[] event makes it possible to build UIs which behave like Decker's Listener.
• Since the user actually does type a newline, you'll need to carefully adjust the vertical sizing of the input field to match the font in order to maintain the illusion that the field is "cleared" instantly when the user presses return.

I hope this helps!

In Lil, the "&" and "|" operators provide logical AND and logical OR. Both "conform" to the elements of lists:

(1,1,0,0) & (1,0,1,0)  # -> (1,0,0,0)
(1,1,0,0) | (1,0,1,0)  # -> (1,1,1,0)

To be more precise, these operators are actually binary "minimum" and "maximum" operators for numbers:

(1,2,3,4) & 2          # -> (1,2,2,2)
(1,2,3,4) | 2          # -> (2,2,3,4)

As always, be careful to remember that Lil expressions are carried out right-to-left unless you include parentheses.

For comparisons, Lil has < (less), > (more), and = (equal). It does not have "compound" symbols like "<=", ">=", or "!=". If you want the complementary operation, you can use ! (negation):

  a > b      # a is more than b
! a > b      # a is not more than b (a <= b)
  a < b      # a is less than b
! a < b      # a is not less than b (a >= b)
  a = b      # a is equal to b
! a = b      # a is not equal to be (a != b)

Note that all of these operations work to lexicographically compare strings, too:

"Apple" < "Aardvark","Blueberry"    # -> (0,1)
"Apple" & "Aardvark","Blueberry"    # -> ("Aardvark","Apple")
"Apple" | "Aardvark","Blueberry"    # -> ("Apple","Blueberry")

Lil syntax highlighting profiles for vim, emacs, and Sublime Text are available at the Decker Github Repo.

Syntax highlighting is also available in the Lil Playground.

Variables that live beyond an event handler must be stored in a widget. If you find it inconvenient to reference widgets on another card,

thatCard.widgets.has_knife.value
thatCard.widgets.has_soap.value
thatCard.widgets.has_corncob.value

You could write utility functions on the card script that aggregate information from widgets:

on get_inventory do
 ("knife","soap","corncob") dict (has_knife,has_soap,has_corncob)..value
end

And then send events at that card from elsewhere:

thatCard.event["get_inventory"]

(Or as shorthand if the event handler doesn't take any arguments,)

thatCard.event.get_inventory

In this way you can give cards an "API" of sorts. You could also define helper functions in the deck-level script to reach into specific cards:

on items do
 thatCard.event.get_inventory
end

And then call that helper function from anywhere in the deck:

items[]

(I think this is probably overkill unless you're accessing the same info in lots of places within a deck.)

You can absolutely use tables to keep track of dialog options. A grid widget stores a table in its "value" attribute. Aside from manually editing table contents as CSV or JSON, you can initialize one with a script:

myGrid.value:insert k v with
 "Tell me about Chickens"  "They cool."
 "Tell me about Daffodils" "They flower."
end

You could append a new row (or several rows) to the existing table in a grid like so:

myGrid.value:insert k v with
 "Tell me about Easter Eggs" "They rare."
into myGrid.value

And you could then later retrieve that table and convert it into the dictionary form dd.chat[] wants by razing it (which turns the first two columns into dictionary keys and values, respectively):

dd.open[deck]
dd.chat["Ask away." (raze myGrid.value)]
dd.close[]

Note that if you plan on revisiting the same dialog tree over the course of a game many times but you don't want to repeat old selections you'll need to do additional bookkeeping; dd.chat[] only remembers/winnows selections within the course of one conversation.

For more information about tables and querying, see Lil, The Query Language.

Does that help point you in the right direction?

The "image.map[]" function can be used to re-palette any Image interface, including card backgrounds. The simplest way to call it is to feed it a dictionary where the keys are the original pattern indices and the values are the replacement pattern indices:

card.image.map[colors.red dict colors.green]

Note that this operation modifies the image in-place.

The difference is that deck parts are "Interface" values, while your later example is a dictionary.

Lil's basic datatypes (numbers, strings, lists, dictionaries, tables, functions) are all immutable values: attempting to modify them will return a new value and leave the original value unchanged.

Interfaces (like most deck parts) are mutable, and accessing or modifying their attributes may have side-effects. For example, modifying the ".index" attribute of a widget to change its order on a card will also visibly modify the ".widgets" property of the container card, since these attributes are related to one another. The "sys" interface exposes "sys.now", an attribute which contains the current Unix timestamp, and may (generally) be different every time it's accessed. Lil also offers utility Interfaces like Array for those times when mutable data structures are necessary for performance reasons.

Does that make sense?

You can inspect and modify the order of widgets on a card via their .index attribute, which counts from back to front, starting at 0. This is automatically clamped within the permissible range on a card, so assigning it to 0 or -1 can be a convenient shorthand for "all the way to the back" and any very large number (say, 999999) can likewise be used for "all the way to the front".

For example, you could give your draggable canvas a script like so:

on click do
 me.index:999999
end

Don't worry- it's quite normal to stash contraption state in auxiliary hidden widgets. The contents of such widgets is distinct between contraption instances, but the background image of contraptions is shared among all instances; pasting directly onto the contraption background will cause issues if you have more than one sprite. The conventional solution would be to add a canvas widget to the contraption and draw on that instead. You'll also need to configure non-zero margins for the contraption to ensure that the canvas automatically stretches and resizes properly along with it. Both the contraption instance and the canvas will need to be set to "show transparent" if you want objects behind the sprite to show through.

Since you intend to redraw the contents of the canvas frequently, you may be able to mark it as volatile, which will ensure that having many sprite instances won't bloat deck size with unnecessary copies of sprite frames. If you aren't already doing something similar, you may find it useful to mark the canvas as "animated" so that it will automatically bubble view[] events to the contraption instance at 60fps and "locked" so that it doesn't inherit the default click-and-drag-to-scribble behavior of canvases. (Be aware that "me" will be bound to the original target of the view[] event, not necessarily the contraption itself!)

The Sokoban example deck contains a contraption called "mover" which works similarly in some ways to your "sprite" design, and the Path example deck has another variant called "follower". You might find these useful to reference.

Does any of this point you in the right direction?

When a field is configured to display "Rich Text", it can contain text spans that are links, use different fonts, or include inline images. Rich Text is described in the reference manual here.

Rich Text is represented as a Lil table, and can be constructed like any other table so long as it has the appropriate columns. For example,

myField.value:insert text font arg with
 "Apple" "" "theAppleCard"
end

Remember, of course, that fields need to be locked for their hyperlinks to be clickable. Unless you define your own link[] handler for a field, clicking a link will call the go[] built-in function with that "arg" value, which conveniently serves either to navigate to cards by name or to prompt the user to open URLs in a new browser tab.

The "RText" utility interface (linked above) offers a number of convenience functions for creating and manipulating Rich Text tables. The "rtext.make[]" function offers a more concise alternative to the above:

myField.value:rtext.make["Apple" "" "theAppleCard"]

In the interactive docs for a variety of modules I use this sort of approach to automatically generate the index in the title card's view[] event handler:

bullet:image["%%IMG0AAYADQAAAAB49Pz8/HgAAAA="]
i:select c:key t:value..widgets.title.text where value..widgets.title from deck.cards
index.value:raze each row in rows i
 rtext.make["" "" bullet],
 rtext.make["  "],
 rtext.make[("%s\n" format row.t) "mono" row.c]
end 

Does that help?

There's a lot of material in this thread that might be helpful.

There are a number of possible approaches for what you're describing. I'll assume that when you say "play a GIF" you intend to use a gif or colorgif contraption?

If you have set up a button to take you to another card, its script might look something like the following:

on click do
 go["otherCard"]
end

If you simply wanted to wait for time to elapse before changing cards, you could use the sleep[] function, which accepts a number of frames to wait as an argument. Decker runs at 60 frames per second, so a 5 second delay would look like this:

on click do
 sleep[5 * 60]
 go["otherCard"]
end

While Decker is sleeping, the user can't interact with other widgets, and contraptions that normally animate or otherwise update themselves on every frame will appear to be "frozen". Some contraptions are designed to allow an external script to explicitly tell them to update themselves; by convention this will often take the form of exposing an .animate[] function which can be called from the outside. I have updated the gif and colorgif contraptions (see above) to support this convention. (If you already have a gif or colorgif contraption in your deck, re-pasting the updated definition from the bazaar will "upgrade" any existing instances of the contraption.)

If the card contained a gif widget named "mygif", we could rewrite the above script to give it a chance to keep running while Decker waits for 5 seconds by using a loop and only sleeping one frame at a time:

on click do
 each in range 5 * 60
  mygif.animate[]
  sleep[1]
 end
 go["otherCard"]
end

You alluded to wanting the GIF to start playing only when the button was clicked in the first place. Perhaps you meant you want the contraption to appear during that interval? This sort of thing can be done by manipulating the .show attribute of the widget. Supposing the contraption was initially set to "Show None",

on click do
 mygif.show:"solid"
 each in range 5 * 60
  mygif.animate[]
  sleep[1]
 end
 mygif.show:"none"
 go["otherCard"]
end

(Note that I reset the GIF to be invisible again at the end; this is not essential, but makes testing easier!)

I'd also like to point out that it's very straightforward to script simple "slideshow" animations with sleep[] by putting each frame on its own card:

on click do
 go["firstCard"]
 sleep[30]
 go["secondCard"]
 sleep[30]
 go["thirdCard"]
 sleep[30]
 # and so on
end

Or more concisely, for many frames of the same delay,

on click do
 each cardName in ("firstCard","secondCard","thirdCard","fourthCard","fifthCard")
  go[cardName]
  sleep[30]
 end
end

Of course, having a very large number of frames in such an animation can also make your deck quite large!

Does any of this point you in the right direction?

&  is AND,   |  is OR.

if thing1.value & thing2.value # AND

if thing1.value | thing2.value # OR

if ! thing1.value # NOT

Do these examples work for what you need? There's more in this post as well.

Could you post the scripts you're trying that work and those which do not work? It's much easier to diagnose problems with scripts when I can read them and clearly understand what you have tried.

Scripts typically can only run while you're in Interact Mode (or from inside the Listener). Likewise, the canvas.brush attribute you mentioned, when it's used in a script it only meaningfully changes the brush setting for that one canvas when the canvas is clicked in Interact Mode, y'know? (I think you knew that, I'm just clarifying for anyone wandering by.)

So, yeah, I don't think it's possible to change your Drawing Mode tool or brush via scripting.

But, in case it's of use to you and your project: 

The Toolbars do extend downwards with an arrow at the bottom if you have more than the default amount of brushes.

 And as a further example, this is how the 'stamp'-style brushes from the brushes example deck appear on the toolbar:

The last one is quite a large stamp, relative to the others, but it's neatly constrained to it's own little rectangle and it's not too hard to figure out which one is which.

I hope this helps, I'm excited to hear that someone is making use of custom brushes!

raze of a table (like the .value of a grid widget) makes a dictionary mapping the first column to the second column. For example,

 insert k v with "Apple" 11 "Banana" 22 end
+----------+----+
| k        | v  |
+----------+----+
| "Apple"  | 11 |
| "Banana" | 22 |
+----------+----+
 raze insert k v with "Apple" 11 "Banana" 22 end
{"Apple":11,"Banana":22}

the dd.chat[] function will exit if the value corresponding to a key in that map is a number (instead of a string or rtext), so we just need to add another entry to that dictionary.

If you have a dictionary in a variable, you can modify it in-place:

 d:raze insert k v with "Apple" 11 "Banana" 22 end
{"Apple":11,"Banana":22}
 d["Cursed Fruit"]:33
{"Apple":11,"Banana":22,"Cursed Fruit":33}

You can also perform the equivalent amendment if the dictionary was yielded by a subexpression, as long as you wrap it in parentheses:

 (raze insert k v with "Apple" 11 "Banana" 22 end)["Cursed Fruit"]:33
{"Apple":11,"Banana":22,"Cursed Fruit":33}

You can also construct a dictionary functionally using "dict" and then take the union of some other dictionary and the new dictionary with ",":

 (list "Cursed Fruit") dict 33
{"Cursed Fruit":33}
 (()["Cursed Fruit"]:33) # (yet another way of saying the above)
{"Cursed Fruit":33}
 (raze insert k v with "Apple" 11 "Banana" 22 end),((list "Cursed Fruit") dict 33)
{"Apple":11,"Banana":22,"Cursed Fruit":33}

Or you could make a second table and join its rows to the original (also with ",") before razing:

 raze insert k v with "Apple" 11 "Banana" 22 end,insert k v with "Cursed Fruit" 33 end
{"Apple":11,"Banana":22,"Cursed Fruit":33}

Many ways to peel this particular apple. I strongly recommend using the Listener to experiment with examples like these whenever you find yourself puzzling over a tricky expression; building things up in little pieces helps you verify an idea as you go.

Do those examples make sense?

From the lil reference manual:

If join is applied to non-table arguments, it produces a list by pairing adjacent elements from x and y. If either argument is a number, it is considered "range" of that argument, and otherwise it is interpreted as a list. For example, "ABC" join 3 gives (("A",0),("B",1),("C",2)).

As you can see, it has a preference for preserving the length of the left argument if they don't match. Some functional languages call this operation on lists "zip()". Applying "join" to tables performs a natural join.

If you simply want to concatenate lists and atoms, use the comma operator (,):

 a1,a2
# ("aa","bb","cc","dd","x")

(Lil doesn't have list literals per se, just atom literals and the comma operator.)

Does that make sense?

Hmm. Could be tricky to make this fast in Lil.

In general, using queries is much more efficient than loops. You can slightly simplify

where (on f x do "r" in x end)@value

as

where value like "*r*"

and you could hoist that "in" out of the loop, since it accepts a list as a left argument. Together, these ideas can make the query much more concise:

on strip x do "" fuse "r" drop x end
still:select word:value wod:strip@value
 where (strip@value) in words
 where value like "*r*"
 from words

...but probably not much faster.

You can also avoid stripping the r's twice by using a "subquery"

still:select where wod in words from
 select word:value wod:strip@value
 where value like "*r*"
 from words

You could use a conditional to compute the extracted column (this is evaluated once per group):

extract if count value first value else () end where 1<count index by value from str

Or you could use the "gindex" column to make the filter retain at most one element per group:

extract where (!gindex)&1<count index by value from str

How's that?

You could define a function which "wraps" the default play[] in the deck-level script, preventing the original from being called unless your flag is set:

on play x y do
  if options.widgets.soundsandmusic.value=1
    send play[x y]
  end
end

The "send" statement is specifically designed to make it easier to set up these kinds of overrides for existing functions. (Overriding go[] has some interesting potential!)

If you think there are some situations where you may want to call play[] normally, a less invasive approach would be to give your wrapper a different name instead of shadowing the built-in function, and to change e.g. all the instances of play["foo"] within your own scripts to sfx["foo"]:

on sfx x do
  if options.widgets.soundsandmusic.value=1
    play[x]
  end
end

Keep in mind that scripts within modules and contraptions don't "see" deck-level definitions, since they're supposed to be reusable from deck to deck. If you're setting up sound effects for dialogizer text, for example, you'll need to perform the same flag-check. This can also be done in a centralized place with deck-level functions.

Does that make sense?

Hello, welcome! I have a simple script for you. Where to put it is going to vary a little bit based on what you're doing.

If you're changing the number inside the slider by having the user click on it, you could put something like this in the slider's script:

on change val do
 if slider1.value > 69 
  button1.locked:0
 end
end

Or, explaining what that means: "Whenever my value is changed (by the user clicking on me), check if my value is above 69. If yes, unlock the button. End (for the if statement). End (for the on change val do event)."

This only unlocks the button -- it doesn't re-lock it if the number goes back down. I'm not sure if that's even something you want, but you could have it re-lock below 70 with an added "else":

on change val do  
 if slider1.value > 69    
  button1.locked:0
  else   
  button1.locked:1  
 end
end

I'm locking and unlocking the button in this example but you can use nearly the same snippet to change the button's visibility instead. 

Rather than using .toggle here I'd prefer to use .show just to feel like I had complete control over it:

on change val do
 if slider1.value > 69 
  button1.show:"solid"  
  else  
  button1.show:"none"  
 end
end

If you end up hiding the button you'll probably want to use .show:"none" rather than .style:"invisible"  in the script.

The difference between them is that even though "None" buttons are effectively locked AND hidden from view... Invisible buttons can still be clicked. This is useful for users who are drawing scenes and want to use buttons as containers for their clickable areas without the standard appearance of a button.

The above scripts are assuming that the slider's value was changed by the user clicking on it and that the script is inside the slider.

But if the slider's value is going up because of something happening in a script somewhere else you could add the "check if >70, unlock or show button" snippet to the end of that other script instead.

For example, a script inside a button which adds +10 to the value of the slider, and also unlocks a button if the new number is more than 70... could look like this:

on click do
 slider1.value: slider1.value+10
  if slider1.value>69
  button1.locked:0
  end
end

I hope this points you in the right direction! If this isn't what you needed, then I'm happy to try again.

I'm pretty sure the Style menu option is only available in drawing mode.

That said... I'm very curious what you're up to with tracing mode, if you're inclined to share.

I often make a timer in a basic widget when I need one.

A simple example:

If you make a field and set it to be "animated" (select the widget, then in the menu select Widgets > Animated) it will experience 60 view events per second.

Since this example is using a field we can also ask it to store a number to keep count of how many view events have happened. And when it reaches a certain number (60 view events multiplied by the number of seconds -- for 60 seconds this is 3600) tell it to do something special.

on view do
me.text:me.text+1
if me.text=3600
#the stuff you want to happen#
 end
end

(When you're writing a script inside a widget, you can refer to that widget as 'me', which is what I'm doing in the script here.)

This may not be needed but you can also make a custom event handler pretty easily:

on view do
me.text:me.text+1
if me.text=3600
my_event[]
 end
end

I'm using the example name "my_event" but you can name it something more specific and then define what happens during this event inside of the same widget's script that uses it (or on a higher level like the card or deck-level scripts) by writing it out like any other event handler:

on my_event do
# the stuff you want to happen #
end

Also there was a recent thread about making timers for someone else's game that has some more discussion, if it's of any use to you: (link here)

Yes, by sending events. A script on CardA can call function "foo" with the argument "bar" on CardB like so:

CardB.event["foo" bar]

This expression returns the result of the function call. In this way you can design cards that act as "APIs" to be called by scripts elsewhere in the deck.

You can likewise call .event[] on widgets. This "synthetic" event is indistinguishable to the target (thatButton) from an event generated by Decker itself:

thatButton.event["click"]

When an event is sent, all the deck parts and other magic variables will be in scope from the perspective of the target: widgets will "see" other widgets on the same card, "me" will be bound to the target, etc.

Yes! A widget's order placement can be modified with .index

For example:

on click do
 me.index:999
end

index:0 places a widget at the bottom of the order, index:999, or any other sufficiently large number, places a widget at the top.

You can put this snippet into an "on drag do" event handler as well.

If you refer to the Decker Reference Manual, grid widgets have a ".rowvalue" property that can be used to obtain the data in the selected row; this will be a dictionary. The "first" of such a dictionary will obtain the value for the first column:

on click do
 f.text:first g.rowvalue
end

In this particular example it would be equivalent to ask for the "key" entry of the dictionary, as that is the name of the first column:

on click do
 f.text:g.rowvalue.key
end

As for adding rows, it looks like you were consulting a very old example from before the "insert" syntax was overhauled. Given a grid "i" with a single column "name", I think you want something closer to:

i.value:insert name with "sworde" into i.value

The Lil Reference Manual has detailed explanations and many examples of the "insert" query form.

Does that make sense?

You may be looking for the "floor" primitive? There's no corresponding "ceiling" primitive but you can take the negation of the floor of the negation:

 select value down:(floor value) up:(-floor-value) from .1*range 21
 
+-------+------+----+
| value | down | up |
+-------+------+----+
| 0     | 0    | 0  |
| 0.1   | 0    | 1  |
| 0.2   | 0    | 1  |
| 0.3   | 0    | 1  |
| 0.4   | 0    | 1  |
| 0.5   | 0    | 1  |
| 0.6   | 0    | 1  |
| 0.7   | 0    | 1  |
| 0.8   | 0    | 1  |
| 0.9   | 0    | 1  |
| 1     | 1    | 1  |
| 1.1   | 1    | 2  |
| 1.2   | 1    | 2  |
| 1.3   | 1    | 2  |
| 1.4   | 1    | 2  |
| 1.5   | 1    | 2  |
| 1.6   | 1    | 2  |
| 1.7   | 1    | 2  |
| 1.8   | 1    | 2  |
| 1.9   | 1    | 2  |
| 2     | 2    | 2  |
+-------+------+----+

You can just say something like:

field1.text:alert["What's your name?" "string"]

Here’s an Ask button that asks the question, and sticks the response into a field:

%%WGT0{"w":[{"name":"field1","type":"field","size":[100,20],"pos":[154,108],"value":"blorp"},{"name":"button1","type":"button","size":[60,20],"pos":[174,74],"script":"on click do\n  field1.text:alert[\"What's your name?\" \"string\"]\nend","text":"Ask"}],"d":{}}

As a follow up, I’ve tried creating variables too, but it didn’t work either.

I’m trying to make an invisible counter tracking the amount of time a player visited a card (and could be reset), so like a numerical variable…

EDIT AGAIN: Counters. That’s how it works. then add +1 to the text. Got it.

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.