You could write a script to record the position of all the canvases automatically (rather than recording every coordinate by hand), stash those positions in a field somewhere, and then have another script re-apply them when appropriate.
Let's say you have widgets something like this:
The "remember" script looks like:
on click do p:select key value..pos where value..type="canvas" from card.widgets positions.data:raze p end
And the "restore" script looks like:
on click do each pos name in positions.data card.widgets[name].pos:pos end end
In practice, this field and buttons will probably be hidden (set to "show none"). If you ever want to record the current state of the canvases without un-hiding the buttons you can simulate a click via the listener:
remember.event.click
Does that make sense?
When the arrow keys are pressed, a navigate[] event is sent to the current card with an argument of "up", "down", "left", or "right". If you wanted to make these events move a canvas, you might have an event handler in the card-level script something like
on navigate dir do
deltas:("up","down","left","right") dict ((list 0,-1),(list 0,1),(list -1,0),(list 1,0))
myCanvas.pos:myCanvas.pos+deltas[dir]*32
end
If you wanted that canvas to trigger "exits" when it matches certain positions, you could mark them with buttons (perhaps set to "Show None") and then send them a "click" event on an overlap; the buttons could in turn go[] to other cards, trigger alert boxes, etc.
on navigate dir do
deltas:("up","down","left","right") dict ((list 0,-1),(list 0,1),(list -1,0),(list 1,0))
myBug.pos:myBug.pos+deltas[dir]*32
each button in extract value where value..type="button" from card.widgets
if button.pos~myBug.pos button.event["click"] end
end
end
For a fully-worked example of a game that uses arrow keys for tile-based movement, you should take a look at Decker Sokoban.
Grid widgets, like this example named "items":
contain tables. You can read or write the table of a grid widget via the .value attribute of the grid. Tables can be indexed numerically (looking up rows) or by strings (looking up columns):
items.value
# +--------------+-------+--------+
# | fruit | price | amount |
# +--------------+-------+--------+
# | "apple" | 1 | 1 |
# | "cherry" | 0.35 | 15 |
# | "banana" | 0.75 | 2 |
# | "durian" | 2.99 | 5 |
# | "elderberry" | 0.92 | 1 |
# +--------------+-------+--------+
items.value[3]
# {"fruit":"durian","price":2.99,"amount":5}
items.value.fruit
# ("apple","cherry","banana","durian","elderberry")
In the simplest case of populating another grid with a specific column of a source grid, assigning a list to the destination grid's .value attribute will implicitly cast it to a table:
dest.value:items.value.fruit
For more complex transformations of data, there's Lil's query language:
select fruit price where amount>2 from items.value # +----------+-------+ # | fruit | price | # +----------+-------+ # | "cherry" | 0.35 | # | "durian" | 2.99 | # +----------+-------+
A query never modifies tables in-place; it returns a new table. Just like before, we can take the source grid's .value, query it, and assign the result to another grid's .value attribute:
dest.value:select fruit amount where fruit in "cherry","banana" from items.value
There are many examples of using queries on tables in the Lil reference manual section Lil, The Query Language. If you aren't using it already, Decker's Listeneris very helpful for trying queries interactively or generally testing out snippets of code.
Does any of that point you in a useful direction? I can try to furnish more specific examples of how to formulate queries for your project if you provide additional detail about how your data is organized.
I did some pondering and tried to come up with an approach that minimizes the amount of scripting needed:
http://beyondloom.com/decker/goofs/petquiz.html
The structure of the deck is as follows:
on click do go["Next"] end
When we get to the last card of the quiz, the user clicks a button to discover their result. The script there will find all the question cards based on the "q_" naming convention, look at all their checkboxes, and count up the number of checks for a given result name. The name which had the most checks will be the name of our result card:
on click do cards:extract value where value..name like "q_*" from deck.cards counts:sum each card in cards raze select key value..value where value..type="button" from card.widgets end go[first extract key orderby value desc from counts] end
This is probably a bit daunting. Using the Listener, we can break this script down step-by-step; assume we're on the card "decide" and we've already filled out our quiz responses.
Find the question cards:
cards:extract value where value..name like "q_*" from deck.cards # (<card>,<card>,<card>)
For now, consider only the first card. Find the button widgets and form a table from their names ("key") and checked status ("value..value"):
select key value..value where value..type="button" from cards[0].widgets # +-----------+-------+ # | key | value | # +-----------+-------+ # | "chicken" | 1 | # | "fish" | 0 | # | "dog" | 0 | # | "cat" | 0 | # +-----------+-------+
Razing a table forms a dictionary mapping its first column to its second column:
raze select key value..value where value..type="button" from cards[0].widgets
# {"chicken":1,"fish":0,"dog":0,"cat":0}
We'll need to do this process for each card, not just the first one:
each card in cards
raze select key value..value where value..type="button" from card.widgets
end
# ({"chicken":1,"fish":0,"dog":0,"cat":0},{"fish":0,"cat":1,"chicken":0,"dog":0},{"dog":0,"chicken":1,"cat":0,"fish":0})
If we sum a list of dictionaries, we'll get a dictionary with the union of the keys in each dictionary and the sum of all the corresponding values:
counts:sum each card in cards
raze select key value..value where value..type="button" from card.widgets
end
# {"chicken":2,"fish":0,"dog":0,"cat":1}
To find the key with the largest value, we'll sort the keys by the values (descending):
extract key orderby value desc from counts
# ("chicken","cat","fish","dog")
The first element of that list is our answer:
first extract key orderby value desc from counts # "chicken"
So we can go[] to the corresponding card by name:
go[first extract key orderby value desc from counts]
This query doesn't care about how many results exist, how many questions are in the quiz, or how many answers are available for each question; you can easily add to the quiz or make an entirely different quiz without modifying the query.
(Note: this quiz won't work right if your checkboxes are named inconsistently. If you seem to get goofy results, you can try the above step-by-step in the Listener to see if you get any unexpected options in this result list!)
Does that make sense?
Decker is fairly well-suited to making dollmaker-style games.
I did a brief writeup on modifying The Ornamented Ovum over on the Decker community forum: https://itch.freezing.top/t/2769322/the-ornamented-ovum . Anyone is welcome to use this game as a starting point for their own creations!
Decker comes with a number of interactive tutorial decks, but the most immediately relevant ones might be All About Draggable and All About Color.