Widgets are the elements inside a layout: text, buttons, images, item icons, the player model, and so on. Each entry in a layout's widgets list is an object with a type field and the type's own settings:
Widgets are not laid out automatically; each one is positioned on its own. The alignment anchors the widget to one of nine points of the layout's padded area, and x/y shift it from there:
top_left top_center top_right
middle_left center middle_right
bottom_left bottom_center bottom_right
For centered alignments the widget's own size is taken into account, so "alignment": "center" with no offsets puts the widget exactly in the middle. Offsets always move the widget right (x) and down (y); use negative values for the other direction. A back button in the bottom right corner, 4 pixels off the edge, would be:
The action property makes buttons do something when pressed. It uses the vanilla dialog action format, so everything vanilla supports works here: minecraft:run_command, minecraft:open_url, minecraft:suggest_command, minecraft:show_dialog, minecraft:copy_to_clipboard, and the dynamic variants.
Palladium adds three more action types:
palladium:open_screen opens another Palladium screen (field screen, the screen ID). This is how you link screens together into multi-page menus.
palladium:open_customization_screen opens the player customization screen (optional field category to jump to a category).
palladium:custom_event sends an event to the server. This is the way to make a button do something server-side beyond running a command; see Custom Events below.
{
"type": "palladium:button",
"text": "Choose your side",
"close_on_press": true,
"properties": {
"action": {
"type": "minecraft:run_command",
"command": "function mypack:choose_side"
}
}
}
Only the two button widgets (palladium:button and palladium:flat_button) execute actions; on all other widgets the action property is ignored. Commands run through actions are executed by the player, with their permission level, exactly like the vanilla dialog system.
The palladium:custom_event action sends an event with a freely chosen ID and optional NBT data to the server:
Field
Type
Required
Description
id
ID
Yes
The event ID. Use your own namespace.
data
Object
No
Arbitrary NBT data sent along with the event.
On the server, the event fires the palladium:custom_event advancement criterion trigger, so anything that listens to criterion triggers can react to it. The main consumer is the automation system, where you can match on the event ID and data and run server-side actions; inside the automation, the event ID and data are also available on the context. It also works as a regular criterion in advancements.
{
"type": "palladium:button",
"text": "Claim reward",
"properties": {
"action": {
"type": "palladium:custom_event",
"id": "mypack:claim_reward",
"data": { "tier": 2 }
}
}
}
Keep in mind that the client decides what it sends: treat an incoming event like a button press, not as trusted data, and put any real checks into the automation's condition.
The visibility property takes the same conditions used everywhere else in Palladium, tested against the viewing player. Since it is re-evaluated every tick while the screen is open, you can build screens that react to the player's state, for example showing a button only once a power is unlocked: