Built-in Menu Guide

That has two practical consequences worth knowing before you touch anything:

• They all behave the same way. Pagination, click gestures, refresh-on-change, Bedrock form fallback, sounds — a habit you learn on one menu carries to every menu.
• They are all themeable. Because the built-ins run on the engine, the same vocabulary you use for a custom menu — materials, MiniMessage names and lore, actions and requirements — is what shapes them. You are never stuck with the shipped look.

The menus you already have

These open from commands (or from clicking through another menu). You do not create or enable them — they ship with their module and appear as soon as that module is on.

What is on the module hub

/uxmess gui draws one tile per module that has a screen you can open from nothing, and hides any tile you lack the permission for, so two staff members with different ranks see different hubs. Clicking a tile opens exactly the same screen the module's own command opens, under the same permission node:

A few modules are deliberately absent:

• tablist, nametags, commandcontrol, servertweaks, vanish have no GUI of their own; they are configured entirely in their .conf files.
• playerstate, invrollback, villagers, trade, security do have GUIs, but each one opens onto a subject you name first: a player (/invsee Bob, /invrestore Bob), the villager you clicked, the partner who accepted your trade, or your own PIN prompt. There is nothing for a hub tile to open.

What every built-in menu shares

Because they all run on the one engine, the following is true of the home grid, the kit browser, the /eco panels and every other built-in alike.

Click gestures

Menus react differently to different clicks. A left-click usually performs the primary action; a right-click, shift-click or middle-click may do something secondary (preview instead of claim, delete instead of open). Where a menu uses more than one gesture on the same tile, its lore says so.

Live refresh

Tiles that show a changing value — a kit's remaining cooldown, your balance in the economy panel, a home's occupancy — re-render on their own while the menu is open. You do not need to close and reopen to see the current number.

Pagination

Lists longer than one page (many warps, a long transaction history) page with the arrow tiles. The page controls sit on pinned slots so they never move as the contents scroll.

Bedrock players get a native form

A player joining through Floodgate/Geyser does not see a chest GUI — the same menu is rendered as a native Bedrock form. Storage-style menus that show real item stacks (the vault, the inventory viewer) stay as a chest even on Bedrock, because a form cannot hold item stacks. See Bedrock Forms.

Re-theming a built-in menu

You theme a built-in the same way you author a custom one — you just edit the file the module already ships instead of creating a new one.

1. Find the panel under plugins/uxmEssentials/modules/<module>/gui/<menu>.conf.
2. Change what you want: an item's material, its name and lore (verbatim MiniMessage), its slot, or add decor { glow = true }.
3. Reload just that module: /uxmess reload <module>.

Delete a key to fall back to its shipped default; delete the whole file to regenerate it from defaults on next load.

Windows that hold real items

A handful of built-ins are not just rows of buttons: they contain real item stacks that move. The trade window, /invsee and /endersee, the villager trade manager and the inventory-rollback snapshot preview all show items you (or the player you are inspecting) actually own.

These are spec files like every other built-in, with one addition. The file hands a block of slots over to the module with a content {} block, and from there on the module owns what happens inside it:

content {
  "playerstate:invsee" {
    slots    = ["0-40"]
    editable = true
  }
}

Everything outside that block is ordinary chrome: a backdrop, a label, a button. Inside it, the module decides what is drawn and which movements are legal, because that is where the rules that stop an item being duplicated live.

What you can change

Move the region wherever you like, and reshape it: the slot list is read straight out of your file, and nothing in the module assumes where the slots sit. Restyle the chrome around it as freely as any other panel.

Three things are not yours to change:

• The region id. It is what connects the block of slots to the module behind it. Rename it and the module no longer recognises its own window.
• The slot count, where the window mirrors something fixed. An inventory viewer needs exactly 41 slots and an ender viewer 27, because that is how many the thing it mirrors has; the snapshot preview needs 45; the two trade regions must be the same size as each other, since one is the mirror of the other. A file that does not add up is refused by name, with the count it needed, instead of opening a window whose slots do not line up.
• The slot order, where it means something. In the villager trade manager the slots come in threes, in the order buy, buy, sell, one triple per trade. Five triples is five editable trades; a villager with more trades keeps the rest untouched behind the window. Declare more triples for more editable trades, but keep the count a multiple of three and keep each triple in that order. There is one villagers:remove-N action per triple, numbered from 1 in region order, so a remove button that moves rows is renumbered rather than guessed from where it sits.

Next Steps

• Custom Menu Engine — build your own menu in menus/<name>.conf.
• Actions & Requirements — the click and visibility vocabulary every menu, built-in or custom, is made of.
• Bedrock Forms — how a menu renders for Floodgate players.
• Per-Module Config — where each module's gui/ panels live.