Application UI DSL

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.

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: it can generate C++ and participate in building the resulting frontend.

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.

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.