Embed or launch ConfigUI
Three integration levels
Engine only |
Depend on uniconfig-core; register vocabulary; build your own UI. |
Component (future) |
Depend on form model + a toolkit binder when split from the desktop shell. |
Full ConfigUI |
Ship or invoke the |
Detect an existing install
Before bundling another copy, check for ConfigUI on the machine:
-
Sibling
uniconfig.exe/uniconfignext to your app -
%LOCALAPPDATA%\Programs\ConfigUI\uniconfig.exe(Windows) -
uniconfigonPATH
The D helper findConfigUiExecutable() (in the ConfigUI app sources today; moving to a shared embed module) returns the path or an empty string.
Policy: prefer the user’s existing install when versions are compatible; bundle only when none is found or you require a pinned version.
Launch modes
Full ConfigUI
Open the main tree. Your registered catalog appears when the user opens matching files:
uniconfig "C:\Users\me\AppData\Local\MyApp\myapp-settings.toml"
Your app can spawn that after registerCatalogSource on startup.
Scoped to your profile (planned)
Pass a profile filter so the left tree highlights your section first:
uniconfig --profile com.mycompany.myapp/settings path\to\file
(Flag wiring is roadmap; registration + open path works today.)
Pared-down shell (roadmap)
Embed only the form binder inside your window — same engine + vocabulary, no global registry chrome. See Components.
Bundle ConfigUI with your installer
-
Ship
uniconfig+fallback-catalog/beside your exe or install to%LOCALAPPDATA%\Programs\ConfigUI\. -
On first run, call registerCatalogSource — do not rely on the installer alone unless it writes the same
catalog-index.sdlentry. -
Add an in-app Settings… action that launches ConfigUI on your config path.
In-process engine (no window)
import uniconfig.core;
auto ctx = makeOpenContext(); // resolver + bundled fallback
auto doc = openDocument("settings.toml", ctx);
// read doc.merged, render your own controls, saveDocument(doc)
Use this when you want native settings UI without shipping the full desktop shell.