ADF

ADF è un'applicazione desktop Rust + eframe/egui per creare ed eseguire interfacce definite in XML, con logica Rhai incorporata. Non richiede .NET, componenti COM legacy o un interprete esterno.

Scarica il pacchetto del tuo sistema dalla pagina Releases ed estrai lo ZIP. Per usare un pacchetto già compilato non serve installare Rust.

Windows, dalla cartella estratta in PowerShell:

# Aprire l'editor
.\adf.exe

# Eseguire CIAO direttamente, senza editor
.\adf.exe ".\examples\ciao.xml"

macOS, dalla cartella contenente ADF.app:

# Aprire l'editor (oppure fare doppio clic su ADF.app)
open ADF.app

# Eseguire CIAO in una nuova istanza, senza editor
open -n ADF.app --args "$PWD/ADF.app/Contents/Resources/examples/ciao.xml"

Gli artefatti non sono firmati con certificato distributivo né notarizzati; il sistema operativo può mostrare avvisi o limitarne l'apertura.

Nell'avvio diretto viene aperto STARTCONTROL; gli script possono aprire altri FORM con show_form. Chiudere STARTCONTROL non termina ADF se restano altre finestre del progetto aperte: ADF termina alla chiusura dell'ultimo FORM visibile, anche se la chiusura è richiesta da uno script. I FORM definiti nell'XML ma mai aperti non mantengono attiva l'applicazione. Un file non valido o uno script legacy non eseguibile mostra un errore; non viene aperto automaticamente l'editor.

Serve Rust stabile, almeno 1.92, con gli strumenti di compilazione della piattaforma: Xcode Command Line Tools su macOS, Visual Studio Build Tools con C++/Windows SDK su Windows.

git clone https://github.com/rsodvd79/ADF.git
cd ADF

# Editor
cargo run --locked

# Esecuzione diretta dell'esempio
cargo run --locked -- "examples/ciao.xml"

# Compilazione ottimizzata
cargo build --release --locked

L'eseguibile è target/release/adf oppure target/release/adf.exe. Su macOS puoi eseguire il build direttamente con:

./target/release/adf "examples/ciao.xml"

Per percorsi contenenti spazi, racchiudi sempre il percorso XML tra virgolette.

• XML: modifica il sorgente e usa Apply / validate. Un XML non valido non sostituisce l'ultimo modello valido. Il designer è bloccato finché le modifiche testuali non sono applicate o scartate.
• Designer: palette trascinabile, albero dei controlli, proprietà/eventi, duplicazione, eliminazione e undo/redo. Nel layout assoluto trascina per spostare e usa la maniglia in basso a destra per ridimensionare; nei layout adattivi trascina su un altro controllo per riordinare.
• Preview usa lo stesso rendering dell'esecuzione, senza avviare script. Ogni FORM in esecuzione è una finestra nativa separata.
• New / Open / Save / Save as / Reload, protezione delle modifiche non salvate, avviso sui file cambiati esternamente, tema sistema/chiaro/scuro e dieci progetti recenti.
• Run / Stop: l'esecuzione usa una copia del progetto. Le modifiche nell'editor si applicano al successivo Run, non al runtime già attivo. In modalità editor, chiudere la finestra iniziale termina il progetto ma lascia aperto l'editor. Nell'avvio diretto da XML, invece, ogni FORM può essere chiuso indipendentemente e ADF termina alla chiusura dell'ultimo.

Le modifiche visuali normalizzano l'XML: non preservano commenti, formattazione o delimitatori CDATA, ma preservano il testo degli script. Undo/redo visuale conserva al massimo 32 modifiche; un trascinamento conta come una sola modifica. Le stringhe Rhai che referenziano controlli devono essere riviste dopo rinomina o duplicazione.

La radice è <ADF VERSION="2" SCRIPT_LANGUAGE="rhai">; restano i concetti PROPERTY/STARTCONTROL, MODULO e CONTROLS/CONTROL. NAME identifica un controllo nel progetto: è univoco e case-sensitive. STARTCONTROL deve referenziare un FORM alla radice.

WIDTH/HEIGHT e TOP/LEFT sono punti logici, non dimensioni esterne Windows Forms. Il layout ABSOLUTE conserva le coordinate; VERTICAL e HORIZONTAL usano ordine, PADDING, SPACING e il flag EXPAND dei widget. Solo FORM può avere figli; i FORM non possono essere annidati.

Esempi:

• examples/ciao.xml: conversione del progetto originale. Premendo OK appare DVD/CIAO; dopo la conferma il pulsante diventa SOMMA = 2 e il titolo della finestra diventa ADF.
• examples/showcase.xml: tutti i controlli, layout adattivi, CHANGE, conferma Sì/No, stato persistente e una seconda finestra.

MODULO viene inizializzato una volta per Run; le sue funzioni sono disponibili a tutti i FORM. CLICK/CHANGE contengono corpi Rhai, non dichiarazioni Sub nome_Click. Gli handler sono compilati prima dell'esecuzione ed eseguiti uno alla volta, non ad ogni frame grafico.

Le variabili top-level di MODULO persistono tra gli handler, ma le funzioni Rhai non catturano implicitamente le variabili globali: per lo stato condiviso dentro funzioni usa get_state/set_state. Le variabili locali introdotte da un handler vengono scartate alla fine. Le modifiche programmatiche non generano CHANGE ricorsivi. Un errore interrompe l'handler, mantenendo le modifiche già effettuate.

I dialoghi bloccano lo script, non il thread GUI. Le finestre del progetto non accettano nuove interazioni durante l'evento/dialogo; in modalità editor, l'editor rimane utilizzabile. Stop e reload annullano lo script senza eseguire le istruzioni successive. Nell'avvio diretto, chiudere l'ultimo FORM annulla anche un eventuale dialogo in attesa.

Per inizializzazione/evento: 100.000 operazioni e un secondo di esecuzione attiva. Il tempo di attesa della risposta a un dialogo è escluso dal timeout; il contatore operazioni non viene azzerato dal dialogo. Stop e timeout sono cooperativi.

Limiti finiti: XML UTF-8 5 MiB, profondità XML 32, massimo 1.000 controlli, testo/script/stringhe 1 MiB, array/mappe e opzioni fino a 10.000 elementi, 64 livelli di chiamata, profondità espressioni 64/32, 256 variabili di scope, 1.024 funzioni e 256 chiavi di stato (128 byte ciascuna, valori scalari). Geometria finita in 0..16384, con dimensioni positive.

DTD, entità esterne, importazioni Rhai da file ed eval sono disabilitati. Gli script non hanno API per file, rete o processi. Queste sono protezioni applicative: non isolamento del processo o garanzia sulla memoria totale. I salvataggi validano prima il sorgente e sostituiscono il file tramite temporaneo nella stessa directory; un errore non elimina il file precedente.

Import legacy apre la struttura XML e preserva gli script originali, ma non li esegue. Gli XML senza versione sono considerati v1/VBScript. Non esiste una traduzione automatica generale: converti MODULO e ogni evento, poi usa Mark scripts converted o modifica gli attributi della radice a v2/Rhai. Salva con un nuovo nome per conservare l'originale.

VBScript: Function SOMMA(X1, X2) ... SOMMA = X1 + X2 ... End Function
Rhai:     fn SOMMA(x1, x2) { x1 + x2 }

VBScript: MsgBox "CIAO", vbOKOnly, "DVD"
Rhai:     message("DVD", "CIAO");

VBScript: ok.text = "SOMMA = " & SOMMA(1,1)
Rhai:     set_text("OK", "SOMMA = " + SOMMA(1,1).to_string());

Prestare attenzione a maiuscole/minuscole degli ID, conversioni dei tipi e valori di ritorno dei dialoghi. Non vengono importati oggetti Windows/COM. Gerarchie, tipi o campi non supportati producono errori, non perdite silenziose.

cargo fmt --all -- --check
cargo test --all-features --locked
cargo clippy --all-targets --all-features --locked -- -D warnings
cargo build --release --locked

Per uno smoke test con finestre reali, serve una sessione desktop e un backend grafico funzionante:

cargo run --locked --features native-smoke --example native_smoke
cargo run --locked --features native-smoke --example native_smoke -- --runtime-only

Il test nativo renderizza CIAO e showcase, conferma i dialoghi tramite il protocollo del worker e verifica risultati, CHANGE, viewport e Stop. La variante --runtime-only verifica l'avvio automatico senza editor e la chiusura indipendente dei form fino all'uscita dell'applicazione. I test egui headless verificano separatamente click, blocco durante eventi e drag-and-drop tramite eventi reali di puntatore. Non sostituiscono una verifica manuale di focus, screen reader e DPI su ciascun sistema.

Il workflow Build and release ADF compila in release a ogni push, su Windows x64 e macOS ARM64, dopo fmt/test/clippy. Solo se entrambi i build riescono pubblica una GitHub Release collegata al commit, con i due ZIP:

ADF.windows.yyyy.MM.dd.HH.mm.zip
ADF.macos.yyyy.MM.dd.HH.mm.zip

Il timestamp è UTC e comune ai due pacchetti. Il tag include anche ID del run e tentativo, evitando collisioni tra push o riesecuzioni nello stesso minuto. Le pull request eseguono le verifiche e caricano gli artefatti senza pubblicare release; l'avvio manuale del workflow pubblica anche la release. La pubblicazione usa GITHUB_TOKEN, con permesso contents: write solo nel job di release, senza secret aggiuntivi.

Su macOS Apple Silicon, dopo cargo build --release --locked:

bash scripts/package-macos.sh
open target/bundle/ADF.app

Il bundle e gli esempi sono inclusi in target/bundle/ADF.macos.<timestamp>.zip. Senza parametri il packaging usa il timestamp UTC corrente; per impostarlo esplicitamente puoi usare, ad esempio:

BUILD_TIMESTAMP=2026.11.08.18.15 bash scripts/package-macos.sh

Il pacchetto Windows contiene adf.exe, README ed esempi XML. Gli artefatti non sono firmati con certificato distributivo né notarizzati. La pubblicazione richiede una scelta di licenza e, per distribuzione firmata, certificati del proprietario.

Il progetto VB.NET resta temporaneamente nel repository come riferimento: va ritirato solo dopo la verifica della sostituzione anche su Windows.

Hot reload automatico, evidenziazione/completamento Rhai, contenitori e tabelle, CLI headless ed esportazione di launcher dedicati. Linux, altre architetture e accesso al sistema con permessi espliciti sono fuori dal perimetro attuale. Non sono inclusi debugger, plugin, cloud o telemetria.

Non è presente un file di licenza. Prima della distribuzione, il proprietario deve definire i termini di utilizzo del software.

Autore: @rsodvd79.