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.