Application UI DSL

UIDEF is UI DEFINITION -- a user-interface definition stored as an x64base DBF design table with a memo sidecar. Not identity, not accounts, not BBS. The acronym went unexpanded on every page that used it until 2026-09-03.

Alpha -- chartered and in progress. AIF-120 is no longer a planned lane waiting to start. The design-table contract, importers, validators, generators and four target backends exist in development. Every lane ruling remains review-needed until the maintainer accepts it.

What the lane is for

Traditional menus and forms as the interface to GUI generation and adaptation -- as a builder, or as an API.

Decades of application interfaces already exist as screen, menu and class definitions. The lane treats them as INPUT rather than as history: read an existing design into a portable table, then emit it against a toolkit chosen now. That is the ADAPTATION half. The GENERATION half is the same path with a new document at the front, authored by a tool or by hand.

The four backends are instruments, not products, and that is why none of them is a rich application. Each one exists to answer a different question about the same document: whether it survives a second toolkit (Tk), whether it survives having no pixels at all (character cell), whether it reaches a browser (HTML), and whether it reaches the engine for real (wxWidgets). A backend that made things pretty would be worse at that job. The lane's own success test says so: a successful render by one toolkit is not enough, and a target that cannot honour something the document says must report the loss by name.

The vocabulary sketch that came first

The original website seed proposed commands such as CREATE WINDOW, CREATE MENU, DEFINE BUTTON, and ON CLICK. That was a useful vocabulary sketch, but it put the syntax before the portable object.

The lane's actual deliverable is a UI definition table: a DBF document with a memo sidecar. A future text DSL can author that table, but generators do not need to parse the text language. They consume the documented table directly.

Why the interface is a database table

FoxPro screen, menu, class, and report designers stored their definitions in DBF-shaped files. That prior art fits x64base unusually well: the engine can open, browse, validate, index, transform, and transport its own application definitions.

The result is an interchange format rather than a toolkit wrapper:

future DSL text or a visual designer
                |
                v
       UIDEF design table (DBF + memo)
                |
                +--> manifest and refusal report
                +--> wxWidgets C++ generator
                +--> Tk renderer
                +--> HTML renderer
                +--> character-cell renderer

The rule shared by every target is simple: if a backend cannot honor something the document says, it reports the loss by name. Silent degradation is the defect.

The design table

The current contract uses three record kinds: DOC, FONT, and OBJ. Its fields carry identity, parentage, layout order, tab order, span, kind, flow, data binding, font reference, provenance, properties, original coordinates, handlers, data sources, and notes.

The object vocabulary covers ordinary controls and application structure:

form panel group pageset page splitter
label text button check radio list combo image menu
grid tree detail summary statusbar

Geometry is expressed as layout intent. FLOW, ORDINAL, Weight, and Fill describe containment and allocation. Imported absolute coordinates stay in ORIGIN, with their units, instead of pretending a pixel and a character cell mean the same thing.

What exists now

Import and authoring

• Authoring tools produce UIDEF DBF/FPT documents and reproducible acceptance and refusal fixtures.
• Importers read FoxPro .SCX, .VCX, and .MNX design tables.
• Class, implied-child, font, encoding, menu-nesting, binding, and layout rules have explicit contracts rather than being inferred independently by each renderer.

Validation before rendering

The manifest reads what a document requires and compares it with a target's declared abilities. Unknown properties, invalid bindings, unresolved sources, unsupported layout, and target-specific losses are reported before a window is presented as successful.

Four backend views

The splitter is a useful portability example. wxWidgets has a native sash; Tk and HTML preserve different subsets of its constraints; the character-cell backend derives a fixed separator. The document carries the full intent, and each target states what it cannot preserve.

Engine integration

Generated wx frontends can open the tables named by their own UIDEF document, resolve location through a workspace, bind grids to the engine's tuple stream, and use the engine's typed locking services. The UIDEF document is also a CMake input: author the document, generate C++ from it, compile it, and link it against the engine, all from cmake --build.

That target is standalone on purpose and is not reached by the root build. Configuring the root build to produce one window would also build the whole shell, so the lane follows the pydottalk precedent (AIF-119) instead. The consequence worth knowing: a normal build never compiles this lane, so it will not appear in a build log.

APPGUI and its alias GUI launch DotTalk++ Workbench through the product's registered GUI path. That proves a shell-to-window launcher, but it is not a UI-DSL command and should not be confused with CREATE WINDOW being live.

The launcher, and the limit of what it proves, in one frame (2026-08-26). appgui prints the path of the executable it starts and starts it. What the same frame shows is that this is all it did: the shell that launched the window reports 0 area(s) open immediately afterwards, while the window holds thirteen areas of its own. A process was started. No interface was described, generated or bound -- which is the distance between APPGUI and CREATE WINDOW. Unrelated desktop windows are masked.

Relationship to Workbench

DotTalk++ Workbench is the project's first-party database application. UIDEF is the description and generation contract for application interfaces, including frontends the project does not own.

Workbench is therefore evidence and a demanding design specimen, not the only target. The lane has already described the Workbench frame as a UIDEF document and generated a recognizable wx structure back from it. That round trip exposed missing proportional-layout vocabulary, which was then added without changing older documents.

Evidence state

Known Alpha boundaries

• The user-facing text DSL has not been implemented. The design table is the current authoring and interchange contract.
• menu still lacks the same depth of first-class proof as the other kinds.
• Data frames need fuller paging and refresh behavior as the cursor moves.
• Nested splitter teardown is proven on Tk, but a wxWidgets lifetime probe currently exposes a fatal teardown defect. Layout proof does not erase that limitation.
• Windows/MSVC support must be established by a current native build before it is promoted as proven here.
• Some engine naming and workspace behavior is being hardened alongside the multi-workspace work; UIDEF must consume those shared services rather than grow private alternatives.

Proof and publication gates

The lane advances when the same document remains intelligible across targets, losses are explicit, generated frontends use the real engine, and the source contracts feed HELP, SelfDoc, manuals, and this website. A successful render by one toolkit is not enough.

This page is the website comparison gate for the Alpha lane. It describes development evidence, not a tagged release or a promise that the proposed text syntax is available today.