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?