There's a lot of room for improvement in Lil performance. The each loop in your example is particularly expensive because "each" is a map operation yielding a result list, range eagerly creates an entire list, and each loop body is executed in its own scope. Contrast with "while", which is considerably faster due to involving less bookkeeping and keeping much less in memory at once:

while x<1000000
  x:1+x
end

Or, when it's possible, just using the natural "conforming" over lists:

1+range 1000000

Performance for each over a huge list is particularly bad in c-lil; I'll do some investigating.

so I tried to get it from js-lil, and I couldn’t manage to copy the string out of the listener. After copying it and pasting it in the script editor, the string appears as an image within the script..

You could use the sleep[] function to wait a given number of frames. "sleep[60]" would delay for approximately one second.

A different approach for timing (which could be more accurate over longer time periods) would be to use `sys.now` or `sys.ms` to record a starting time and then consult them periodically to determine how much time has passed, possibly using "sleep[]" to delay between checks. (See: the System interface)

sleep[] looks a bit unsatisfying, as the card is not interactive as it waits, so the label isn’t that readable.

I have tried this:

Make a textfield to store a timer (here I used “timer”) initially set to 0. You can put it on another card if you want to hide it out the way.

Card:

on view do
 timer.text:timer.text+1
 if (timer.text<0) & ((10%timer.text)=0)
   display.text:display.text - 1 
 end
 go[card]
end

Button:

on click do
 timer.text:(display.text+1)*-10
end

Edit: I was late to the party. Using sys.now as suggested above sounds like a more suitable approach :)

To make a hyperlink in a field, ensure that it is a "Rich Text" field (the default for new fields), switch to the Interact tool, and select a region of text within the field. You can then use the "Text -> Link..." menu item to create a hyperlink, which will be shown with a dotted underline. When you're finished editing, to make the hyperlinks "clickable" you must lock the field, by switching to the Widget tool, selecting the field, and choosing the "Widgets -> Locked" menu item.

Fields emit a "link" event when a hyperlink is clicked, which you can intercept with a script to do as you please. If you don't write a script, the default behavior is to go[] to the text you provided when you created the hyperlink. If that's the name of a card, it will navigate to that card. If it's a url like "http://google.com" it will ask the web browser to open a new tab.

Hope that helps clear things up!

I think the simplest way to get the edge cases you want would be using "()," to coerce lists or scalars to lists, and using "() unless" to coerce an empty result with "first" to an empty list.

  (),extract () unless first value by value from "ABBBCD"
("A","B","C","D")
  (),extract () unless first value by value from "AAAA"
("A")
  (),extract () unless first value by value from ""
()

The former coercion is always valid, but the latter does require some care depending on the data; this is the nasty side of unifying nullity and a numeric value:

  (),extract () unless first value by value from 1,1,0,5,1,2,0,1
(1,5,2)

Edit: and another approach entirely would be to use "dict":

  range (11,22,33,0,11,22) dict ()
(11,22,33,0)
  range (11,11) dict ()
(11)
  range (0) dict ()
(0)
  range () dict ()
()

Depending upon the context, you might not even need the "range".

If you have a canvas containing the image, you can change visibility using the show attribute:

canvas_name.show: "none"
canvas_name.show: "solid"

To show or hide it on a delay, there is a simple way and a more complex way.

The simple way uses the sleep function. It (mostly) pauses the whole program until it’s finished sleeping. For example, you could use it in a button’s click action:

# Simple, e.g. button script
on click do
  card.widgets.canvas_name.show: "none"
  sleep[60] # number of frames to sleep for
  card.widgets.canvas_name.show: "solid"
end

Complex uses sys.ms and recursive go[] functions to allow other things to occur in the meanwhile. You’d need a hidden field to store some extra data. Here the image shows after 1s.

# Complex, with a field called hidden_time
# Button script
on click do
  card.widgets.canvas_name.show: "none"
  card.widgets.hidden_time.text: sys.ms
  go[card]
end
# Card script
on view do
  elapsed: sys.ms - card.widgets.hidden_time.text
  if elapsed > 1000
    card.widgets.canvas_name.show: "solid"
  else
    go[card]
  end
end

Plotting (or reading out) individual pixels on a Canvas (or an Image interface) is possible; just index or assign through them with an (x,y) pair as if they were a list or dictionary.

Plotting a large number of pixels will be fairly slow, since doing so will force the Lil interpreter to do a large number of serial operations. Both canvases and images provide a variety of higher-level methods for scaling, transforming, and drawing which operate upon pixels in bulk, and should generally be preferred, especially if the goal is any sort of realtime animation.

You can hide Decker's menu bar by "locking" a deck. In the main menu, choose "File -> Properties..". and then click "Protect..." to save a locked copy of the current deck.

In the deck file itself, this adds a line like:

locked:1

You can also manipulate whether a deck is locked on the fly by setting "deck.locked" in a script:

on click do
 deck.locked:!deck.locked
end

(Careful, though; if you use scripts to lock a deck you haven't saved yet you might get yourself stuck!)

Edit: oh, and if you meant hide the menu bar while editing, pressing "m" on your keyboard while using drawing tools will temporarily toggle the visibility of the main menu, allowing you to draw "underneath" it.

There isn't currently any kind of volume control; volumes are effectively "baked into" the amplitude of a sound's samples.

A slightly clumsy workaround would be to make a copy of an existing sound on the fly and use sound.map[] to rescale its samples. Assuming the deck contains a sound clip named "sosumi":

on play_scaled name vol do
  r:-128+range 256
  play[sound[deck.sounds[name].encoded].map[r dict floor vol*r]]
end
on click do
  play_scaled["sosumi"   1] # normal  volume
  sleep["play"]
  play_scaled["sosumi"  .5] # half    volume
  sleep["play"]
  play_scaled["sosumi" .25] # quarter volume
  sleep["play"]
  play_scaled["sosumi" .10] # 1/10th  volume
end

In Decker, persistent state lives in widgets. If you want to remember anything beyond the scope of an event handler, it should be stored in a widget. For example:

If you want to remember something without showing it to a user, you could use invisible widgets, or widgets on a hidden card.

The walkthrough and examples in this thread might be helpful to you.

I recommend checking out The Listener as a way of interactively trying short snippets of code. You can use the Listener to poke and prod at the contents of a deck or card and verify behaviors before you write a script.

The print[] and show[] Built-In Functions can be used to log information (formatted text or arbitrary Lil values, respectively) to the Listener for debugging. The alert[] function can sometimes be handy for debugging because it pauses the current script and displays text to the user. The panic[] function stops scripts completely, but can likewise be a tool for peering into the workings of complex scripts.

Does any of that help?

Decker does not have the ability to execute shell commands or otherwise interact with the host system without explicit user permission; "shell[]" and similar functions are part of Lilt, which has a similar but distinct set of APIs from Decker itself.

As it happens, there is a way to print to stdout from Decker in the latest source revisions- the "app.print[]" and "app.show[]" functions. Note that this feature is not part of Decker v1.31, the current release at time of writing.

There is  presently no mechanism for polling from stdin. The closest analogy might be to use the alert[] function:

alert["please input a string:" "string"]

I think I follow you.

Copying rich text from one field to another requires accessing their "value" property. Let's say we have rich text fields name "target", "a", and "b". The "a" field contains a link, and the "b" field does not:

In the button above I have a script like this which randomly picks between the value of "a" and "b":

on click do
  target.value:random[(list a.value),(list b.value)]
end

In this example, the values each need to be wrapped in a sublist with the "list" operator before joining them together with "," to prevent the rich text tables from being fused together into a single table.

The "a" and "b" fields could be hidden from view (Widgets -> Show None), and this approach generalizes to any number of alternative texts.

If you want to programmatically modify existing rich text to insert links it's a bit more complicated. Rich text is represented in Decker as a table, and the rtext interface contains some functions that can make it easier to manipulate such a table. If you wanted to change the styling of a specific range of characters within a field, you could use rtext.span[] to grab the text before and after your region of interest, retaining their existing styling, rtext.string[] to extract a region of interest without its styling, rtext.make[] to create a new styled chunk (including a hyperlink or inline image), and rtext.cat[] to glue all the pieces back together. If this is a road you need to go down I can try to furnish a more detailed example if you clarify your requirements. The dialogizer demo deck uses rtext functions to build its index on the fly.

Does that help at all?

Sure- there are several ways to approach something like this!

The "in" operator can be used to check a string against a hardcoded list of valid options:

on click do
  if display.text in ("Keyword1","Keyword2","Keyword3")
   go[display.text "SlideLeft"]
  else
   alert["404: Page not found."]
  end
end

And it is also possible to obtain a list of valid card names from the deck; deck.cards is a dictionary from card names to cards:

on click do
  if display.text in deck.cards
   go[display.text "SlideLeft"]
  else
   alert["No such card, I'm afraid."]
  end
end

It might be a good idea to make the comparison case-insensitive if a user is typing free input. The easiest way to handle this would be to make sure the card names are all lowercase and then to convert the user input to lowercase with the "format" operator before doing any checks:

on click do
  t:"%l" format display.text
  if t in keys deck.cards
   go[t "SlideLeft"]
  else
   alert["I don't know anything about that."]
  ends
end

Yet another option is to make a dictionary to associate one or more keywords with destination cards; this provides more options for "forgiveness" in input handling:

on click do
  words["reindeerflotilla" ]:"puzzle1"
  words["reindeer flotilla"]:"puzzle1"
  words["reindeer"         ]:"puzzle1"
  words["smashthestate"    ]:"puzzle2"
  words["smash the state"  ]:"puzzle2"
  
  t:"%l" format display.text
  if t in words
   go[words[t] "BoxIn"]
  else
   alert["that's bogus!"]
  end
end

Does that make sense?

Could you describe what you're trying to accomplish in a bit more detail?

Is the idea that you'd just be stacking copies of images on top of one another repeatedly, or is it more like "gradually reveal a series of layered images"? Do you want this effect on a single card, or is it something you want to repeat in a variety of places with different images?

Hmm.

I suspect "tooted.value.1" should probably be "tooted.value~1" or even just "tooted.value", and you don't appear to be doing anything with the variable "c" or defining anything for the variable "o".

Dialogizer runs "synchronously", blocking most forms of input while its dialogs are open. You shouldn't be able to drag widgets around, click buttons, etc, while a dialog is open, but when you close the dialog and the initiating script finishes everything should be back to normal.

Is the problem that you want to drag the Interior while the dialog is open, or does it somehow cease working even after the dialog has been closed?

The default handler for the "loop" event provided by Decker looks like this:

on loop prev do
 prev
end

This handler is why the background loop plays forever by default; every time the loop ends, this function asks for the same sound to be played again.

If you write a deck-level script (File -> Properties -> Script...) which defines a replacement:

on loop do
 0
end

Then the loop will stop on all cards that do not have their own "on loop ... end" handler which overrides the above.

Does that make sense?

The number formatting issue has been patched in v1.37

Hm. Well, the first step (if you haven't done it already) would probably be stubbing out keyboard navigation, with a card- or deck-level script that overrides navigate[] to do nothing, to make sure the player can't accidentally go to your "protected" card without using editing tools:

on navigate do
end

Then you need some way of keeping track of whether cards have been "visited". Several ways to handle this. If you had an invisible checkbox on every card that needed to be visited named "visited", you could record visits something like so in each card's script:

on view do
  visited.value:1
end

Or even handle it automatically with a deck-level script fragment (not inside a function handler, just bare):

deck.card.widgets.visited.value:1

Left bare, it will execute whenever *any* event is processed. On cards without a "visited" checkbox it will have  no effect.

Check if every card with such a checkbox was checked using a query:

if min extract value..value where value from deck.cards..widgets.visited
  # ...
end

The ".." can be read as "at every index". The minimum of a list of 1/0 values is equivalent to logically ANDing them all together.

And you might want a button somewhere for resetting all the visited checks:

on click do
  deck.cards..widgets.visited.value:0
end

The nice thing about this approach is that as you add new cards in the future, you can decide on an individual basis whether they need to be counted toward "visiting everywhere".

Make sense?

Not currently.

If you're familiar with JavaScript it is relatively straightforward to install new primitives in the Lil interpreter by modifying an HTML build of Decker. This thread includes an example of exposing browser localStorage to Lil.

Async communication is somewhat awkward; if you were to expose an API based on callbacks, like the underlying JS APIs, you could easily end up with Lil functions attached via closure to parts of a deck that have been modified or destroyed since the original call was performed. A polling-based system exposed on an Interface might be less error-prone.

Here's a sketch (untested) of a polling-based wrapper for XMLHttpRequests:

const pending_messages=[]
interface_messagebox=lmi((self,i,x)=>{
   if(ikey(i,'send'))return lmnat(([url,verb,text,id])=>{
     const x=new XMLHttpRequest()
     x.onreadystatechange=_=>{
       if(x.readyState!=XMLHttpRequest.DONE||x.status!=200)return
       pending_messages.push(lmd(['text','id'].map(lms),[lms(x.responseText),id?id:NONE]))
     }
     x.open(verb?ls(verb):'POST',url?ls(url):'')
     x.send(text?ls(text):'')
     return NONE
   })
   if(ikey(i,'poll'))return lmnat(_=>pending_messages.length?pending_messages.shift():NONE)
   return x?x:NONE
})

WebSockets add some additional complexity because the connections need to be persistent, but a similar approach might work.

Widgets do not expose an attribute with a reference to the card that contains them. There are, however, several ways to accomplish what you describe.

Whenever a widget's event handler is fired, a number of variables will be in scope, including:

• "me": the recipient of the event
• "deck": the current deck
• "card": the current card (there's some additional subtlety to this in Contraptions, which I will omit for clarity)
• all of the widgets on the same card, according to their names
• all of the cards in the deck, according to their names

So, for example, your button script might look something like:

on click do
 me.text:card.name
end

If the button happened to be named "myButton" and the card it was on happened to be named "myCard" you could equivalently say:

on click do
 myButton.text:myCard.name
end

Another way to access cards is via the deck. The "deck.card" attribute is the card that the user is presently viewing. Generally this will be the same as the "card" variable, but "deck.card" might be more up-to-date if you happen to go[] to another card midway through a script. Thus, we could also write the example as:

on click do
 me.text:deck.card.name
end

The mechanics of events are described in more detail in the Decker Reference Manual.

Does that answer your question?

The ideal place to ask questions or submit bug reports about Dialogizer is the Dialogizer thread.

Rich text is represented as a table. While the "," operator applied to a pair of strings will form a list of strings, it will concatenate the rows of a pair of tables into a single table. We need to be a little more careful when we want to create a list of tables.

The "list" operator can solve this problem; it wraps any value in a length-1 list. The "," operator will join those length-1 lists together instead of the values they contain. Try constructing your list of choices for dd.ask[] like so:

(list field8.value),(list field9.value)

If the only special thing about the rtexts is the use of a single particular font, you could alternatively give the choices as plain strings and set the "bfont" option when you set up dialogizer; this will apply the specified font as the default for all the dd.ask[] choices:

o.bfont:"swedishFontName"
dd.open[deck o]
...

For general dialogs there's also "tfont" for the default font of the body text in dd.say[] and dd.ask[] boxes.

The go[] function is used to navigate to a different card.

There are three ways to specify the card you want:

• by index: if you provide a number n, go[n] will navigate to the nth card in the deck, counting from 0.
• by name: if you provide a string s, go[s] will navigate to the card with that name.
• by value: if you provide a card c, go[c] will navigate to the card you provided.

Navigating by index is usually not a great idea, because adding or removing cards can easily break such a script. We'll use navigation by value for these examples.

The numeric value of a slider widget can be viewed through its .value attribute.

To turn a numeric index into a card value, we'll make a list of cards and index into it using the slider's .value.

To slightly simplify your example, let's say you have a slider named "mySlider" with a range from 0 to 2, and cards named cardA, cardB, and cardC.

Forming a list:

(cardA,cardB,cardC)

Forming a list and then indexing it:

(cardA,cardB,cardC)[mySlider.value]

So the full button's script could be:

on click do
 go[(cardA,cardB,cardC)[mySlider.value]]
end

And of course, if you want a smoother transition you can specify go[]'s optional arguments for a transition style and delay:

on click do
 go[(cardA,cardB,cardC)[mySlider.value] "BoxIn" 15]
end 

This kind of approach also works if you don't need/want all the destinations to be distinct. Consider:

on click do
 go[(cardA,cardA,cardB,cardC,cardB)[mySlider.value]]
end

Is that clear?

The first example is very straightforward: widgets have a .toggle[] method. If you call it with a single argument it will alternate the value of their .show attribute between "none" and the string specified ("solid", "transparent", or "invert"):

on click do
  a.toggle["solid"]
end

You can see more examples of .toggle[] in the release notes.

Cycling through displaying several different widgets is a bit more complicated.

One approach would be to test the .show attributes of widgets, find which one is currently visible, and then set the .show attributes of all the widgets in a group in order to advance to the "next" selection. The main issue here is it's very ugly and inconvenient to add more widgets to the cycle:

on click do
  if     "solid"~a.show a.show:c.show:"none" b.show:"solid"
  elseif "solid"~b.show b.show:a.show:"none" c.show:"solid"
  else                  c.show:b.show:"none" a.show:"solid"
  end
end

We can reduce repetition and make maintenance a bit easier by making a list of widgets of interest, scanning for them in a loop, and using an index modulo the length of the list to pick the next item:

on click do
  cycle:a,b,c
  current:0
  each wid index in cycle
    if "solid"~wid.show current:index end
  end
  cycle..show:"none"
  cycle[(count cycle)%1+current].show:"solid"
end

If we want to get really clever, there's also a "vector-oriented" way to handle that search instead of an each-loop. In general, multiplying a list of integers [0,n) by a length-n list containing zeroes and a single one will "mask out" the index of the one:

(0,1,2,3)*(1,0,0,0)   # (0,0,0,0)
(0,1,2,3)*(0,1,0,0)   # (0,1,0,0)
(0,1,2,3)*(0,0,1,0)   # (0,0,2,0)
(0,1,2,3)*(0,0,0,1)   # (0,0,0,3)

So we could compute "current" like so:

Giving a complete script as follows:

on click do
  cycle:a,b,c
  current:sum(range count cycle)*"solid"=cycle..show
  cycle..show:"none"
  cycle[(count cycle)%1+current].show:"solid"
end

If you want to include "don't show anything" in the cycle, you can add a "0" dummy element to the list of widgets; 0.show will always be 0, which is not equal to the string "show", and attempting to set the .show property of a number is likewise harmless:

on click do
  cycle:0,a,b,c
  current:sum(range count cycle)*"solid"=cycle..show
  cycle..show:"none"
  cycle[(count cycle)%1+current].show:"solid"
end

Does that answer the question?

Edit: one more note: depending on what you're trying to do it might be worth considering using a slider widget instead of a button; Sliders naturally represent choosing between a range of integers, which could represent an index into a list:

on change val do
  cycle:0,a,b,c
  cycle..show:"none"
  cycle[val].show:"solid"
end

See also, the enum contraption.

The "in" operator can test whether a substring is present in a string:

 "upon" in "stars upon thars"
1

To use this on a column, we could define a helper function. While we're at it, this can also lowercase the column we're searching for a case-insensitive match:

on like needle haystack do
     each v in (list "%l")format haystack
         needle in v
     end
end

Allowing us to write a query like so:

ex:insert Date Entry with
     20210412 "Once Upon A Time"
     20220709 "There once were"
     20230101 "stars upon thars"
end
select where like["upon" Entry] from ex
# +----------+--------------------+
# | Date     | Entry              |
# +----------+--------------------+
# | 20210412 | "Once Upon A Time" |
# | 20230101 | "stars upon thars" |
# +----------+--------------------+

How's that?

The straightforward way is to use the "list" operator, which wraps its argument in a length-1 list:

 (list "foo") dict (list "bar") 
{"foo":"bar"}

A fancier, more concise way (provided your keys are strings) is to perform an amending assignment to an empty list, like so:

 ().foo:"bar"
{"foo":"bar"}

To obtain a list of the cards with a particular group number you could use a query something like

c:extract value where value..widgets.group.text=2 from deck.cards

(Note that if a 'group' field doesn't exist it will behave the same as a card in group "0"; you probably want to count from 1 for your groups)

Given that list, you can pick a random item and navigate to some card like so:

go[random[c]]

Or, all at once,

go[random[extract value where value..widgets.group.text=2 from deck.cards]]

Does that make sense?

You can adjust the widths of the columns of a grid to hide trailing columns. In "Interact" mode, a small draggable handle appears between column headers:

You can reset the columns to their default uniform spacing with the "Reset Widths" button in grid properties.

Manually resizing column widths enforces a minimum size. You can set column widths to 0 programmatically via "grid.widths", but a 0-width column looks a bit odd; I'll make a note to fix that in the next release.

Starting from the two fields you describe:

You can obtain the text of either field through its ".text" attribute. The "split" operator breaks a string on the right at instances of the string on the left and produces a list. Splitting one string on spaces gets us part of the way to what you're asking for. We can then use the comma operator to join a pair of lists.

" " split field1.text

The best way to experiment with this sort of thing is to use The Listener. Ask a "question", get an answer:

Another approach for gathering space-separated words from several fields would be to use an "each" loop:

Does that help point you in the right direction?

The Lil "comma" operator forms a list by combining the elements of its left and right arguments.

If you use this operator to combine a table and a number, the table will be coerced to its list interpretation (a list of the rows of the table, each a dictionary), and then combined with the number 1 (whose only element is itself), forming a list of several dictionaries and the number 1. Applied to such a list, random[] will occasionally choose the 1.

When you call a Lil function with multiple arguments, commas should not be placed between arguments. You probably meant

random[temp 1]

 Instead of

random[temp,1]

Furthermore, note that if you specify 1 as a second argument to random[] you will get a length-1 list as a result, whereas if you call random[] with only a single argument you will get a single value.

In preparing this post I have also observed that there is some inconsistency between native-decker and web-decker with respect to applying random[] to table values, which may have compounded the confusion; I'll have this fixed in the v1.41 release tomorrow. In the meantime the alternative is to explicitly crack the table into rows before making a random selection, like so:

random[(rows temp)]

Lilt uses a fixed seed by default; this is a design decision inherited from K.

One simple way to randomize it would be something like

sys.seed:sys.ms

Note that Decker automatically randomizes the RNG seed at startup.

In the context of query clauses, column names refer to the entire column as a list. The "where" clause expects an expression which yields a list of boolean values. Arithmetic operators like =, <, and + conform over list-list and list-scalar arguments.

Depending on how a predicate is written, it might naturally generalize to operating on lists for the same reason. For example: 

on iseven x do 0=2%x end
iseven[5]
# 0
iseven[11,22,33]
# (0,1,0)
extract value where iseven[value] from 11,24,3,8
# (24,8)

If a predicate is only designed to operate on a single scalar value at a time, you can use the "@" operator to apply it to each element of a column, like so:

on seconde x do x[1]="e" end
extract value where seconde@value from "Lemon","Lime","Soda","Demon"
# ("Lemon","Demon")

This shorthand is semantically equivalent to

extract value where each v in value seconde[v] end from "Lemon","Lime","Soda","Demon"

(And of course in this particular case the "like" operator would be simpler:)

extract value where value like ".e*" from "Lemon","Lime","Soda","Demon"

Does that clear things up?

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?