# ValaDialog (v1.0.0) - High-Performance GTK3 Drop-In Framework

ValaDialog is a native, compiled GTK3 drop-in replacement for the legacy gtkdialog utility in Puppy Linux. It is architected to parse and execute hundreds of unedited legacy Bash UI scripts, guaranteeing bit-perfect drop-in compatibility while modernizing the interface subsystem to GTK3.

## 1. System Architecture & Processing Pipeline

The layout transformation engine operates in a strict, deterministic three-tier pipeline. Because legacy shell scripts frequently feed malformed, unquoted, or multi-tag XML strings, the processing boundaries are decoupled as follows:

- Phase 1: Raw Legacy XML Payload -> XmlPreprocessor (Subshell Solver & Sanitizer)
- Phase 2: Valid XML text nodes -> XmlTransformer (State-Machine & Unique Top-Level Mapping)
- Phase 3: GtkBuilder layout string -> Gtk.Builder Runtime (RAM Allocation & Bash Exporter)

### Technical Blueprint of the Pipeline Phases:

1. XmlPreprocessor (Phase 1):
* Extracts embedded input configuration structures and executes the raw nested Bash pipelines synchronously via GLib.Process.spawn_sync.
* Strips harmful trailing null-bytes (\0) thrown by quick kernel streams (e.g., /proc/modules) that would otherwise act as early string terminators in the underlying C-libraries.
* Sanitizes illegal XML text patterns inside rows. For instance, X11/Network interface state flags containing angle brackets (e.g., <UP,BROADCAST>) are mapped to square brackets ([UP,BROADCAST]) to prevent layout-parsing collisions.
* Processes compact multi-tag single lines (e.g., <hbox><text><label>Hi</label></text></hbox>) by hard-injecting a newline character before every < token, isolating each XML tag into its own state loop iteration.

2. XmlTransformer (Phase 2):
* Performs an ahead-of-time regex pass to collect all instances of structural widgets (<list>, <tree>, <slider>, <spinbutton>).
* Declares non-widget storage containers - specifically GtkAdjustment and GtkListStore objects - directly at the top-level branch beneath the interface tag.
* Enforces a duplicate protection barrier (!sb.str.contains) inside the pre-generation phase. If a widget variable name is evaluated multiple times across the original shell script, the generator suppresses subsequent declarations, stopping layout-parser crashes due to duplicate IDs.
* Runs a linear state-machine tokenizer via a newline loop. Every open widget tag increments an array-mirror layout depth (STACK PUSH), which is strictly reduced when its closing tag variant is verified (STACK POP).

3. PuppyWidgets (Layout Matrix Helper):
* Maps legacy token identifiers to explicit modern GtkBuilder widget markup classes.
* Operates on a strict single-level opening and closing symmetry requirement: every single layout component must open the exact same number of nested structural layers at start (append_element_start) as it collapses at end (append_element_end).

4. Runtime & Exporter Core (valadialog.vala):
* Feeds the fully transformed string payload to the native engine using Gtk.Builder.add_from_string.
* Safely maps asynchronous runtime timer hooks and click signals into standard GLib main loops.
* Upon an explicit OK button event, the exporter iterates exclusively over active, variable-attributed components inside the allocation tree, extracts their state parameters (e.g., selection strings, integer counters, boolean toggles), and pipes clean, eval-ready environment variable key-pairs to stdout. Widgets without a named variable are bypassed to protect the shell environment from garbage generation.


## 2. API & Component Implementations

### GtkScale / GtkSpinButton (Sliders)
* XML Mapping: Declares an isolated, unique GtkAdjustment utilizing a standardized naming schema (id="adj_VARIABLE"). The functional widget inside the interface container references this schema using a primitive property assignment (<property name="adjustment">adj_VARIABLE</property>).
* Symmetry Benefit: Bypasses memory assignment segmentation faults inside GTK3 C-libraries triggered when adjustments are loaded inside inline properties or children.

### GtkTreeView (Lists / Trees)
* XML Mapping: Instantiates a single GtkListStore structural element using a native gchararray column definitions array on the top-level tree layer.
* Layout Layout: The visible display layout element is instantiated as a standalone GtkTreeView nested within a GtkScrolledWindow layout frame. It enforces runtime properties (min-content-height=120, propagate-natural-height=true) to prevent the table frame from shrinking into a hidden scrolling strip when containing short task items (e.g., ps process outputs).

### GtkProgressBar
* Hierarchy Mirroring: Because modern progress bars do not expose a legacy text label property, the transformer references the current stack state to verify the widget parent. It intercepts nested label instances inside a progress bar environment and transparently rewrites them to the required property name="text" element.

## 3. Compilation & Local Testing

The workspace leverages meson and ninja automation pipelines for multi-architecture builds.

```bash
# Purge build tree and install production binary
./build.sh clean
./build.sh install

# Activate standard developer tracing environment
# Pipes stack balancing routines and GtkBuilder warnings directly to stderr:
valadialog --debug --program=YOUR_SHELL_VARIABLE
```

## 4. Known Engineering Limitations & Architectural Incompatibilities

While ValaDialog covers over 98% of standard legacy usage via its multi-phase sanitization pipeline, the structural migration from the legacy row-by-row layout engine of gtkdialog to the strict XML Document Object Model (DOM) tree validation enforced by Gtk.Builder (GTK3) creates several unresolvable edge-cases. Developers must be explicitly aware of the following architectural boundaries:

### 1. Hardcoded Widget Attributes and Signal Mapping Constraints
* The Constraint: Legacy scripts often hook deep custom X11/GTK event loops via inline attributes like <action signal="button-press-event"> or <action condition="command">.
* The Reality: The XmlTransformer maps standard events (clicked, toggled, changed). Custom low-level Gdk signals or complex attribute-driven condition parameters embedded inside the action tags are silently ignored. If a script relies on inline condition evaluation logic rather than pure shell execution, it will fail to update state components as expected.

### 2. Strict XML DOM Trees vs. Malformed Multi-Root Layouts
* The Constraint: Legacy gtkdialog was highly forgiving of structurally invalid layout markup. It would happily skip closed elements or allow arbitrary components to float as direct children of the window node.
* The Reality: Gtk.Builder requires a strict single-child policy beneath the GtkWindow boundary. Our transformer hard-maps the root element to a single GtkBox container. If a legacy script defines multiple independent layout roots outside of an explicit container block, or heavily violates element tree alignment, the resulting XML tree structure might become distorted, resulting in either visual layout breakage or a silent engine exit at Gtk.Builder runtime.

### 3. Missing Widget Class Features (Advanced UI Elements)
* The Constraint: Some legacy Puppy scripts utilize specific, advanced gtkdialog widgets that do not have direct 1-to-1 counterparts in standard GTK3 layouts without writing significant boilerplate code.
* The Reality: Elements like <pixmap> (with complex custom shell-reloading loops), <terminal>, or <colorbutton> are currently unmapped or simplified. If an unmapped tag is parsed, it is ignored by the state machine to prevent a crash. The layout will compile, but the missing components will disappear from the screen.

### 4. Direct Terminal/Stdio Interaction Loop Blocks
* The Constraint: Certain configuration wizards run interactive console commands inside an action block, waiting for automated text or keyboard interrupts from the user's terminal stream.
* The Reality: ValaDialog executes bash subshells completely detached via GLib.Process.spawn_command_line_sync to maintain interface stability. If an action invokes an interactive blocking command (like an un-flagged gpg, passwd, or an interactive fdisk confirmation script), the entire user interface loop will hang indefinitely without presenting the prompt to the user's current shell matrix.

