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?