GacUI: a C++ UI library where the UI is XML, the logic is Workflow, and the renderer can live in another process

What GacUI is for, and who it is aimed at

GacUI is a native C++ user interface library. It targets developers who want a desktop GUI without leaving C++, and who are willing to describe the interface in XML instead of constructing widgets imperatively. The README lists four platform implementations: Windows in the Release repo, Linux in wGac, macOS in iGac, and HTML5 in GacJS. Windows, Linux and macOS are described as native renderers; a TUI renderer also exists, and the screenshots include a TUI theme.

The design assumes you are comfortable with a specific toolchain. The README states plainly that using the library means using C++ source files directly, from the Release folder for Vlpp, Workflow or GacUI, plus GacGen.exe if you prefer XML, plus GacBuild.ps1 when an application has multiple GacUI XML resources with dependencies. That is a source-drop model, not a package-manager model. If your build system expects a stable ABI or a versioned artifact, this is friction you will feel on day one.

The audience is closer to a team building a long-lived desktop product than to someone prototyping a small tool. The feature list is aimed at that scale: control templates you can rewrite, container controls with MVC and virtual list modes, data binding, and an optional cross-process split between the UI core and the renderer.

The Core/Renderer split and what it buys you

The headline architectural idea is that the Core and the Renderer can run in different processes. GacUI Remote Protocol is described as enabling exactly that, in any programming language. The README says it is currently under development, and that demos exist to try it. In GacUISrc.sln, the remoting and remote-view-model demos use RemotingTest_Core.vcxproj and RemotingTest_Rendering_Win32.vcxproj, which shows the intended shape: one project holds the core side, another holds the Win32 rendering side.

The README also describes Named Pipe, HTTP and MiniHTTP as transports. Windows HTTP and cross-platform MiniHTTP expose the same Controls, Dom and IO contract. MiniHTTP is used by the remoting demos and the README states it is not part of GacUI's public API yet. That is a meaningful caveat: if you build against MiniHTTP, you are building on something the project itself has not committed to.

The same separation appears one level up, in MVVM. The README says a View Model can be implemented in another process, in your favourite programming language, with FFI integration starting from interface definitions written in the Workflow script. So the split is not only about pixels: the logic behind the view can also be remote. That is an unusual amount of process-boundary flexibility for a C++ toolkit, and it is the part of GacUI that has no obvious equivalent in the alternatives named in the related searches.

XML, Workflow, and the GacGen.exe round trip

The UI description format is XML, and the scripting layer is Workflow. GacGen.exe consumes XML and produces C++ code behind plus a compressed binary resource containing images. The README recommends generating XML and Workflow into C++ source files for static linking, because that lets you opt out of C++ dynamic reflection, which the README says significantly improves performance and reduces binary size. Dynamic loading with C++ dynamic reflection is the other mode, for loading foreign UI with complex behaviour at runtime.

The regeneration model has one rule worth internalising. GacGen.exe merges your C++ edits with your XML edits, and your changes survive only inside markers that the README describes as an obvious mark, USERIMPL(/* ... */). Anything you write outside those places is discarded on the next run. That is a workable contract, but it means your code-behind file is not yours to structure freely. The README also suggests preferring MVVM and data binding over filling in event handlers in the generated files, which is consistent with the rest of the design.

Data binding and event handler statements can be written in Workflow rather than C++. Interfaces needed to build an MVVM pattern are declared in XML, and GacGen.exe generates the C++ interface declaration. The cost is that a new contributor has to learn Workflow to read the UI layer, even if they know C++ well.

Getting the sources and generating a first window

The README does not give a package-manager install. It points at the Release repo for the Windows implementation and at wGac, iGac and GacJS for the other platforms, and it says to use C++ source files from the Release folder for Vlpp, Workflow or GacUI. The tutorial linked from the README, at the documentation site under gacui/running.html, is where the project says to start. The README does not spell out a compiler invocation, so what follows is the shape of the workflow rather than a complete build recipe.

The README says the source code in this repository is for reference only, and that you should use the source code in the Release repo. That is where the usable sources live for Vlpp, Workflow and GacUI.

Release/

For the XML route the README points at the code generator in the Tools directory, and for applications with several XML resources with dependencies it points at GacBuild.ps1 in the Release repo.

Tools/GacGen

When GacGen.exe runs over your XML, it emits C++ code behind and a binary resource. Your edits belong inside the generated markers, which the README shows as USERIMPL.

USERIMPL(/* ... */)

The README notes that you will see this mark in the generated code and that it is where you add your code, while all your modification outside these places will be discarded on the next GacGen.exe run. The README does not document a rollback path if a regeneration goes wrong, so keep the XML under version control before you run the generator.

Automation when the screen is locked, and how it is exposed

The README makes a specific claim that is easy to miss: GacUI applications can be understood and operated by coding agents, and this works even when the screen is locked and does not block you from using the computer. The mechanism is that UI Automation does not work when the screen is locked, so GacUI exposes UIA features through an HTTP server brought up with the application. The README says the service must be explicitly activated in the source code for security reasons, which is the right default.

The composition sequence is described concretely: construct the concrete service matching the active normal, hosted, core or renderer controller, substitute it, start either the Windows HTTP or MiniHTTP endpoint, run GuiApplication, then stop the endpoint and service before unsubstituting it. Windows HTTP and cross-platform MiniHTTP expose the same Controls, Dom and IO contract. The repository also contains Tools/UiaList, shown in the screenshots as a Windows UI Automation Inspector.

Two limits are worth stating. The service is opt-in, so an application that never activates it has no such endpoint. And MiniHTTP, the cross-platform variant, is not public API yet, so a portable automation setup rests on an interface the project has not frozen.

Where GacUI is the wrong choice

The clearest limitation is stated in the README itself: all text box related controls are not supported yet in the remote protocol, though they are described as on the way. If your application is form-heavy and you wanted the Core/Renderer split, that split will not carry your text input today. You would either keep the renderer in-process or wait.

The second limitation is the source-drop distribution model. There is no retrieved release for this repository, and the README directs you to sibling repositories for usable source. Teams that depend on a package manager, a pinned version and a reproducible artifact will have to build that discipline themselves around the Release repo and GacBuild.ps1.

The third is the language surface. A new contributor reads XML, Workflow and generated C++ with USERIMPL markers, on top of the C++ they already know. For a small utility, that is more machinery than the problem deserves. For a Windows-only tool, the cross-process and cross-platform features are dead weight, and a toolkit that does not ask you to learn a scripting language will get you to a window faster.

How it compares with FTXUI, Nuklear and nanogui

The related searches put GacUI in the same mental bucket as FTXUI C++, Nuklear and nanogui, so the difference in approach is worth spelling out. Nuklear and nanogui are immediate-mode or lightweight retained-mode libraries that you drive from C or C++ calls: you build the interface in code, and there is no separate description format or generator step. GacUI asks for the opposite: you describe the interface in XML, generate C++ and a binary resource, and write bindings in Workflow. The trade is more upfront structure for a UI that can be regenerated and merged rather than rewritten by hand.

FTXUI is a terminal UI library. GacUI also has a TUI renderer, so the two overlap there, but GacUI's TUI is one renderer among several behind the same core, alongside native renderers and HTML5. The distinguishing piece is the process boundary: the README describes Core and Renderer running in different processes speaking a remote protocol over Named Pipe, HTTP or MiniHTTP, and a View Model that can be implemented in another language. None of the immediate-mode libraries named above are organised around that split, because their model assumes the widget code and the drawing code are the same program.

Licence and maintenance questions you have to settle yourself

The repository metadata reports NOASSERTION for the licence, and the README does not resolve it. It says to read the LICENSE first, that the project is licensed under the License repo, and that source in this repository is for reference only while usable source lives in the Release repo. That is three separate statements, and none of them tells you the terms. If you are shipping a product, read the License repository before you write code, and note that source you copy from this repository is described as reference-only, which may not be the same grant as the Release repo.

On maintenance, the last push to this repository was on 2026-09-24, four days before this writing, and the repository is not archived. That is the only maintenance signal available here, and it is a signal about commit activity, not about release cadence or API stability. There are no retrieved releases, so upgrade cost cannot be estimated from release notes. Practically, upgrading means re-pulling sources from the Release repo and re-running GacGen.exe or GacBuild.ps1 over your XML, which is why the USERIMPL boundary matters: it is what keeps a regeneration from erasing your work.

Editorial conclusion

GacUI suits C++ teams that want a native, GPU-accelerated toolkit with MVVM and data binding rather than hand-written widget code, and that accept a source-drop workflow. It is a poor fit if you need a stable released binary, if you want the Core/Renderer split for text-heavy forms today (text box controls are not supported yet), or if you are targeting Windows only and would rather not take on XML and Workflow as a second language. Before adopting, verify the licence terms in the License repo, since the repository reports NOASSERTION and the README points at a separate licence repository, and check which of the four platform repositories matches your target.

Frequently asked questions

Official sources

1. Issues
2. README
3. vczh-libraries/GacUI on GitHub