Built-in Menu Guide

Almost every GUI in uxmEssentials, from the home grid to the /eco panels to the /uxmess gui hub, is drawn by the same engine that loads your own menus/*.conf files.

Two things follow. Every menu behaves the same way, so pagination, click gestures, live refresh, the Bedrock fallback and sounds are one habit rather than twelve. And every menu is themeable with the same vocabulary a custom menu uses: materials, MiniMessage names and lore, actions and requirements.

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.

These are management GUIs, not custom menus. The built-in panels live in each module's modules/<module>/gui/ folder as their own .conf files. They are loaded by the always-on management framework and styled with the same engine grammar as your menus/*.conf files, but they are wired to type-safe feature handlers, so a click there does real work (charging a balance, issuing a ban) that a plain custom menu could not do on its own.

What every built-in menu shares

Re-theming a built-in menu

Theming a built-in works like authoring a custom one, except you edit the file the module already ships.

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.

Read-only means read-only. A region marked editable = false (the trade mirror, the snapshot preview) refuses every movement: clicks, drags, shift-clicks, hotbar swaps and double-clicks alike. You cannot make it editable from the file, and that is deliberate: those stacks are a view of something that belongs to someone else.

Related: Custom Menu Engine, Actions & Requirements, Bedrock Forms, Per-Module Config