Module design 

The .yui screen designer’s backend: the canvas drawn by yog-ui itself (the crate mods render with in game) through a recording YogGfxApi, rasterized with Minecraft’s own font and textures from the local game files; a preview mode driving the same tree with real UI events (click:X:Y, scroll:DY, scrollbar drags); and code-behind handlers.

Modules

advancements

A tab of the game’s advancements screen, drawn as the game draws it (AdvancementsScreen, AdvancementTab, AdvancementWidget, TreeNodePosition of 1.20.1–1.21.1): the tree laid out by the game’s algorithm, the window, the root’s background, the connectors, the frames and icons, and a hovered advancement’s title bar and description — in the game’s font, on a screen of [SCREEN] GUI pixels.

assets

Minecraft’s own resources, read from the user’s local game files — the client jar a Gradle dev setup (Loom, ForgeGradle, NeoGradle) or the official launcher already downloaded, plus its asset index/objects — so the designer draws with the game’s font and textures. Nothing is bundled or redistributed: when no client jar is found the designer says so and draws with what it has (flat rects, a fallback glyph box).

blocks3d

draw2d_blocks in the designer: blocks in 3D, as the game draws them in a GUI (an orthographic view, turned and tilted), each block a cube with its model’s boxes (elements: a cable’s core, a slab’s half) with their textures — the faces you’d see, back to front, the top lit, the sides shaded like Minecraft’s. A model without elements is a cube. A block state picks its blockstate’s variant (turned by its x/y) or every multipart part whose when it meets; elements keep their own rotations.

book

The .ybook designer’s backend: the book drawn by yog-book itself — the renderer the game runs — through the recording YogGfxApi, and clicked through like a reader would (docs/books.md).

codebehind

Event handlers in a screen’s code-behind — what double-clicking a button in Visual Studio’s designer does: foo.yui’s on_click="play" gets an events::PLAY => play(), arm in the match over click(event) in foo.rs and an empty fn play(), and the editor opens there. An existing arm is just navigated to. A missing foo.rs is created with the usual skeleton (ui_include!, on_event, register).

components

A mod’s .yui components (src/**/*.yui with a <Component> root — Yog-IDLE’s docs/yui.md, “Components”), read straight from their markup: no build needed to list them in the toolbox, to edit one in the designer, or to draw an instance whose bindings only name its own properties (text="{x:Bind label}") — the instance is expanded in place, its values substituted. Components whose bindings call code ({x:Bind caption()}) are compiled: the designer host draws those with the mod’s library (custom).

content

The block/item model editor’s backend (.yblock / .yitem, see docs/blocks-items.md): textures as the editor names them, the texture picker’s list, vanilla/parent models for preview, and yog import.

custom

The mod’s .yui components in the designer. Markup-only ones are expanded in place (components); compiled ones — whose bindings call the code-behind — are drawn for real by the mod’s code: a designer host process (host) per mod loads the mod’s library built for this machine (yog designer-lib) and draws them on request.

data

Yog Data text (the yog-data crate: JSON plus comments, trailing commas and unquoted keys) as serde_json values, for the readers here that only look things up.

files

A project’s files, by format.

font

Minecraft’s text renderer, reproduced from its font definitions: the font/*.json provider lists (reference, space, bitmap, unihex, ttf) resolved through Resources, glyph metrics computed the way the game computes them (bitmap advance = trimmed width × scale + 1, unifont advance = width / 2 + 1, …), and § formatting codes. Text drawn through this matches the game pixel for pixel.

gfx

A YogGfxApi table whose draw2d_* functions record into a display list instead of drawing — the game’s side of the ABI, played by the IDE, so yog-ui’s own render (the code that runs in game) produces the designer’s picture. The GPU half of the table is inert.

host

The designer host: a child process of the IDE (yog designer-host) that loads a mod’s library built for this machine (yog designer-lib) and draws the mod’s custom .yui components through the same recording YogGfxApi the designer uses — the mod’s own yog-ui and build code, out of the IDE’s process, so a panicking/crashing/looping component (or a rebuilt library) costs a restart of the host, never the IDE.

images

<Image> in the designer: Yog image sources (item:apple, sprite:button, mod:gui/logo, mymod:gui/logo — see yog_gfx::image) resolved against the local game files and the mod’s assets/, the way the Yog runtime resolves them in game: yog-ui’s Image widget lays out and fits the picture, then calls draw2d_image / image_size, which the recording table (gfx) answers from here. Also the Properties window’s source picker (candidates, preview).

item_models

Items as the game’s item models show them in a GUI, for what plain textures don’t cover: layered models (with their tints — spawn eggs, potions, leather) and builtin/entity heads, drawn as a 3D head.

markup

A .yui tree (as the designer holds it) → the yog_ui::Widget tree the generated .g.rs builds in game — the same builder calls yog build emits (yog-cli yui.rs), made directly instead of as source — wrapped like the generated root_with (the screen panel, anchored).

mod_ui

A mod’s .yui that books and recipes use — its kinds of book page (book_page) and its recipe layouts (recipe_layout) — read with yog-book’s own reader and compiler, as yog build reads them.

project

A mod project as the designers see it: the manifest at its root and the mod a file is in.

raster

The designer’s stand-in for the game’s DrawContext: a display list of draw2d_* calls (what yog-ui’s renderer — or a mod’s own render code — issues) rasterized the way the Yog hosts draw them in game: coordinates truncated to whole GUI pixels (NativeDraw casts with (int)), alpha blending, Minecraft’s font (see font) and textures. Output is RGBA at scale physical pixels per GUI pixel, for the canvas to show with nearest-neighbour scaling.

recipe_area

A <RecipeArea kind="…"> on an inventory screen, as yog build makes it (yog-cli’s recipe_area): the kind’s layout — its places and result real slots, numbered after the screen’s own, its pictures and stations drawn — in a canvas of the layout’s size.

recipe_kinds

Kinds of recipe for the recipe editor — the game’s (yog_registry’s built-in definitions) and the mod’s own (.ydef kind: "recipe_kind"), all described the same way: their slots (and the .yrecipe fields the game’s are written in), their values, and — the layout books show them by (built in, or a .yui recipe_layout) — the picture (images, the station, slot frames) with where slots, result and texts go on it.

refs

What a content reference (@<kind>:<id>) can name, for the designers’ pickers — the same three sources yog build checks references against: the mod’s own content (content/), the other mods’ ids it declares in yog.toml ([external.<namespace>]) and the game’s (read from the client jar on this machine, when there is one). And the mod’s own .ydefs of a kind with what they say (an advancement’s parent, an effect’s color), for the designers that draw several at once.

service

The designers as yog serve methods: what a tool (Yog-IDLE) asks to draw, list or change, by the name it calls it and with its parameters.

tags

What an item tag holds (#minecraft:planks), for slots that show each of its items in turn, as JEI does: the mod’s own tags as yog build makes them (its .yog-build/generated/tags.json — content files’ tags, .ydef tags), and the game’s — from the newest version that has the tag (one removed in 1.21 still shows its 1.20 items) — nested tags opened. Yog’s common tags (yog:ingots/iron) are the game’s and the loaders’ tags they stand for, and a loader’s (c:, forge:) holds what yog_formats::tags says.

worldgen

The .ydef dimension designer’s preview: its terrain generated by yog-worldgen — the code the runtime generates the game’s chunks with — and drawn from above and in a slice.

yui_codegen

.yui screen files (the screen designer’s format) — regenerating their code (.yog-build/generated/**/*.g.rs, what the code-behind pulls in with yog_api::ui_include!) when one is saved, through yog ui gen — and the same for .yres resource files (resources/<Set>.g.rs, through yog res check).

Structs

AssetsInfo

Where the game resources came from (None: no client jar found).

EventArgs

EventResult

GridRects

NodeRect

A laid-out widget: its border box and its content box (inside padding), GUI px.

RenderArgs

Rendered

Functions

event

mod_root

The mod a file belongs to: the folder with its yog.toml (else the folder holding the src/ it’s in).

render

reset

Forgets a file’s preview state (scroll positions).

this_cli

This CLI as a command, for a design call that runs one of its subcommands: the running binary when it’s yog, else the yog on PATH.