Swipes that move between cards generate navigate[] events, just like pressing the left or right arrow keys. You can override the default behavior by defining an empty handler for the navigate[] event on the card- or deck-level script, like so:

on navigate do
 
end

Does that solve your problem?

While Dialogizer is active, the view[] events requested by flagging a widget as .animated won't be produced naturally by Decker itself; all system events are "blocked" until the synchronous call to dd.say[] completes. Dialogizer sends a "synthetic" animate[] event to the current card every frame, and then you can in turn use that event to explicitly send a view[] event to other widgets that need to animate (or call the view[] function on the card, etc).

Perhaps your card script could have something like:

on animate do
 if alarm.animated
  alarm.event["view"]
 end
end

Or maybe you could do something a little more generic, querying the card to find any animated widgets and pump view[] events to them:

on animate do
 (extract value where value..animated from card.widgets)..event["view"]
end

This animate[] event is also how Puppeteer manages the animation for puppets. If you're using these libraries together, make sure your own animate[] event handler calls

pt.animate[deck]

at some point. You can also take a look at the card script for this part of the Dialogizer tutorial: http://beyondloom.com/decker/dialog.html#eventpumping

Does that help?

It would be reasonably straightforward to sort the sound, prototype, and font lists alphabetically when they are displayed.

Is there a specific workflow that you're having trouble with?

The phrase

deck:some_function[]

calls a function named "some_function" with no arguments and then assigns the result of calling that function to a variable named "deck". If the result of that function isn't the deck (it appears to be the number "1" in your example), you will then be calling the dialogizer functions with an invalid "deck" argument, which prevents them from working correctly.

If you have defined a function in a deck-level script:

on some_function argument do
 argument+2
end

You can invoke it from any card- or widget- level script by calling it like any other function:

some_function[3]

Widget scripts exist in a scope nested inside card scripts, which in turn exist in a scope nested inside the deck level script which in turn is nested inside a special magical scope with the definitions of all the default event handlers. Every variable or function definition in an outer scope is visible to the scopes nested within it, unless one of those scopes "shadows" it with a local definition with the same name.

Widgets, Cards, and the Deck all expose a ".event" attribute which is a function you can call to send a synthetic event to that deck-part. You can thus also invoke that deck-level function from elsewhere like so:

deck.event["some_function" 3]

This latter method works even if the target is not in a scope surrounding the caller, and it sets up automatic variable bindings ("me", the widgets on a card by name, etc) from the perspective of the target. This is most useful when you want to communicate across cards or simulate user interaction, like sending a button widget a "click" event which appears from that button's perspective like a user-generated click.

Does that help clarify?

There are a few ways to do what I think you're asking for. You can set a canvas to have a "scale" setting greater than 1 to upscale whatever is drawn on it, and then draw text on it, or you could draw text on a canvas normally, copy the contents of the canvas as an image, upscale that, and then draw the upscaled image back to the canvas.

Presuming we start with the glyph editor in "All About Fonts", we could do the following:

1) create a new canvas widget and name it "upscaled". From its "Canvas properties" modal, set the scale factor as "2" (just for starters).

2) modify the card script, adding the following three lines to the "on view ..." function after the line that reads "sample.font:f"

upscaled.font:f
upscaled.clear[]
upscaled.text[sample.text (0,0),(1,2)*upscaled.lsize]

(This will word-wrap the beginning of the text in the "sample" field within the canvas, with a little extra room so it cuts off instead of ellipsizing)

3) tweak the "sample" field so that it triggers an update of the UI whenever it is changed by giving it a script like so:

on change do
 view[]
end

Now the upscaled preview will be updated whenever you draw on the glyph, change other font parameters, or type in the sample field. You can also adjust the "scale" property of the canvas as desired:

How's that?

In Lil, the number 0, the empty string "", nil, the empty list (), or an empty dictionary is considered false and anything else is considered true. Most of the time, 1 and 0 are the clearest way to indicate true or false, respectively.

Your examples should probably be

on click do 
 canvas1.draggable:1
end

and

on click do
 canvas1.draggable:0
end

Does that make sense?

In interact mode, you can drag dividers between the column headers to adjust their sizes:

If you ever want to "unfix" the column widths you can click "Reset Widths" from the grid properties panel.

You can also set the column widths of a grid with scripts or via the Listener with the "grid.widths" property, which accepts a list of column widths in pixels:

mygrid.widths:60,30

Manual resizing constrains the minimum width of columns so that you can always distinguish their drag handles, but with scripting/the Listener it is possible to set columns to 0 pixels wide, as a way of hiding columns from the user without removing them from the underlying table.

Does that make sense?

As Flocon noted, Decker uses paletted color and doesn't have any notion of partial transparency, so there are some limits to what we can do here, but I can see ways to achieve something like the effect you describe. If you haven't already, I recommend reading through All About Color for some relevant background information.

Let's assume for simplicity that you're using Decker's default color palette, the "map" and "route" cards are fully in black-and-white (patterns 0 and 1), and everything you want to fade in is part of the card backgrounds (no text in fields, etc).

If we created a new card to tinker with, we could use a script in The Listener to composite the card backgrounds together, assigning a different color to the pixels of "map":

card.image.paste[map.image.copy[].map[1 dict 36]]
card.image.paste[route.image.copy[] 0,0 1]

(Be careful to save before doing this sort of thing in the Listener; it's a very powerful tool, but you can't "undo" changes performed this way!)

We could then manipulate the color Decker uses to display the "map" (I picked 36 here arbitrarily) to fade it in or out on the fly. Here I have a slider with a range of 0-255 wired up to let me change it manually:

on change do
 patterns[36]:"%06h" parse 6 take "%02h" format me.value
end

The way I'm computing the "packed RGB" grayscale value here is by turning the 0-255 value of the slider into a 2-digit hex code, replicating it 3 times, and then parsing the result as a 6-digit hex number, which may be a little confusing. All About Color has some functions in the "col" module to make computing packed colors a bit easier.

How's that for a starting point?

The zazz.march[] function is designed for very simple looping animations. It is tied to Decker's global frame counter, which makes it easy to use, but limits its flexibility.

If you have an animation that involves starting and stopping- or even starting and finishing- on a more detailed schedule, like a "cutscene", I'd recommend taking a look at Puppeteer. It defines a language for moving "puppets" around on the screen in various ways, playing sounds on cue, and quite a bit more.

The "ease" module offers another lower-level alternative, with functions for tweening a position along a spline defined by a series of control points.

Does any of that help?

If you have an image in your clipboard, you can paste it into a canvas without altering the size of the canvas by using the Listener. The image is represented in your clipboard as a string that probably looks something like "%%IMG3..."

thatCanvas.paste[image["%%IMG3..."]]

If you wanted to center the image within the canvas, you could tweak this recipe a little. You may also want to clear the canvas before pasting if you already have something drawn on it:

i:image["%%IMG3..."]
thatCanvas.clear[]
thatCanvas.paste[i .5*thatCanvas.size-i.size]

The Listener is also really handy for things like setting widgets to a precise size:

thatCanvas.size:120,100

How's that?

You can define commands that change the style of dialog boxes mid-stream, including sound effects.

You'll need to define the handler for these commands either at the card level (if they're only used in one scene), or at the deck level (if they're used in multiple scenes). If you're also using Puppeteer, your custom command handler needs to ultimately defer to pt.command[] as its default case.

Does that make sense? I can furnish a more complete example if the one in the docs isn't clear enough on its own.

I've also thought about this! But Internet-Janitor is totally correct about all the technical stuff. I think it would require someone very familiar with both Decker and the specifics of 3DS homebrew applications in order to bridge the gap and make sure things run well on the hardware.

But if anyone ever builds a way to port Decker games over to run on the 3DS then I think I would be very fun and cool to make some at the correct size for the screens and then try them out! (Maybe someday...!)

Do you have a widget on the active card named "place2" where you want your dialog box centered?

On the example on the documentation card for the ".pos" setting that is the name of a button widget set to "show none".

So, first thing is referring to widgets on another card. This is easy, for a canvas named canvas1 on a card named card1 it's just card1.widgets.canvas1 (although if you have spaces in the names it is a bit messier)

The second issue might be that from my understanding, flipbook is designed for having all the frames in one image together, rather than split across multiple canvases. So you may need to rearrange how you've got the frames, i.e. combine them all into a single canvas rather than each in their own widget.

How do you want to turn the deck into a PDF? Are you expecting to use the PDF export module that comes with Decker or Millie’s zine template?

The Image Interface and Canvas Interface are different, but they do have things in common, like .outline[], .merge[], .copy[], and .paste[].

image[pos] is described like this:

The pattern index of an (x,y) pixel of the image. Reads nil out of bounds, ignores out of bounds writes. r/w.

canvas[pos] is described like this:

The pattern index of an (x,y) pixel of the canvas. Reads 0 out of bounds, ignores out of bounds writes. r/w.

The only difference is that canvas[pos] is described as returning 0 if you ask for a pixel outside the edges, but that seems to be incorrect - in my testing canvas[-1,-1] returns nil just like an image.