EUI-NEO: a C++17 UI framework whose quick start is missing its clone command

A GPUI name on a tree with no Rust manifest

The one-line summary for the project calls EUI-NEO a cross-platform, high-performance, low-overhead C++17 GPUI framework. The word GPUI never comes back in the README body, and the repository root holds CMakeLists.txt with no Cargo.toml beside it, so nothing here compiles through Cargo. What the framework actually is, by its own description further down, is a C++17 UI framework with GLFW/SDL2 window backends and OpenGL/Vulkan render backends. The layers underneath match that second description rather than the summary. `core/` carries the DSL, the runtime, primitives, text, image, network and platform code, `components/` builds reusable widgets on top of that DSL, and `include/` is the public include path holding `eui_neo.h` plus the `eui/*` facade headers. Optional pieces such as keyboard and serial support live in `modules/`. One claim is left without numbers: no benchmark table appears anywhere in the README, and the only directory that could hold one is `tests/`, described as probe sources, fixture apps and local benchmark notes. The last push to the repository landed on 2026-10-06.

Two window backends, two render backends, no switch shown

Backends are picked in two places at once. The window layer is GLFW or SDL2 and the render layer is OpenGL or Vulkan, so what you choose is a pair rather than a single setting. One of the four is settled for you: the requirements list names OpenGL development files as needed for the default renderer, which makes OpenGL the default and Vulkan the route you take yourself. `eui_neo_configure_app()` is described as adding the selected GLFW/SDL2 entry point, yet nothing in the quick start shows where that selection takes place. No CMake option, cache variable or preprocessor define for a windowing backend appears in the snippet you are told to copy, and the README hands SDL2/Vulkan selection to the Integration Guide at `docs/集成指南.md`. Both switches therefore live in a Chinese-named file, outside the path a new user is steered through first.

The quick start stops one line before the clone command

Follow the Quick Start as written and it loses a line. The instruction says to add EUI-NEO under `3rd/EUI-NEO`, then create, and no object follows that colon. What comes next is the fallback paragraph, offering the AtomGit mirror when the GitHub clone fails, and it prints the only clone command in the whole document:

git clone https://atomgit.com/sudoevolve/EUI-NEO.git 3rd/EUI-NEO

A reader who follows the steps literally clones from atomgit.com as their first action. A reader on a network that cannot reach that mirror has nothing else to copy, because the primary command the fallback refers to is never written down. Installation by `FetchContent` and the SDL2/Vulkan selection are passed on to the same Integration Guide, while building the repository itself is delegated to `docs/开发与发布.md`. The only other pointers given are a Chinese README and a project website at sudoevolve.github.io/EUI-NEO/.

The CMake recipe that survives a copy and paste

Everything after the clone step does work as printed. The host project declares CMake 3.14 as its floor, turns C++17 on for the whole project, points `add_subdirectory` at `3rd/EUI-NEO`, and lets a single function finish the wiring:

cmake_minimum_required(VERSION 3.14)
project(MyProject LANGUAGES C CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_subdirectory(3rd/EUI-NEO)

add_executable(my_app main.cpp)
eui_neo_configure_app(my_app)

Toolchain requirements are pinned to names and versions: MSVC 19.29+ (Visual Studio 2019 16.11+), GCC/MinGW-w64 12+, or Clang 14+. Two commands configure and build, passing the same configuration name to the build type and to the multi-config generator flag:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --config Release --parallel

Which binary you launch next depends on the generator rather than on the framework. Visual Studio places it inside the configuration folder, so the path carries a backslash and a configuration directory:

.\build\Release\my_app.exe

Single-config generators drop it at the build root instead, so on Linux or macOS the same program sits at:

./build/my_app

One column, two node ids, and a lambda that closes it

The entire sample application composes one column in ten lines. `compose` receives a `eui::Ui&` and a `eui::Screen&`, asks the facade for a column node carrying the string id `root`, sizes it from the screen, pads it by 32.0f and hands the interior to a lambda:

void compose(eui::Ui& ui, const eui::Screen& screen) {
    ui.column("root")
        .size(screen.width, screen.height)
        .padding(32.0f)
        .content([&] {
            ui.text("title")
                .text("Hello EUI-NEO")
                .fontSize(28.0f)
                .build();
        })
        .build();
}

Every node is closed by `build()`, so nesting is expressed by call order instead of braces, and the inner lambda runs while the column is being assembled rather than after it. Watch the identifier `text`, which carries two separate jobs. `ui.text` is a factory call that creates a node with the id `title`, whereas `.text("Hello EUI-NEO")` is the setter that drops a string into a node that already exists. Ids are plain strings throughout, and the sample gives no rule for what happens when two nodes share one.

Two app entry points the sample never registers

Each application supplies two functions, and the sample shows where they live but not how they are found. `DslAppConfig` is constructed once as a static and returned by reference from `dslAppConfig()`, with `.title("My App")`, `.pageId("my_app")` and `.windowSize(960, 640)` chained onto it. `compose` sits beside it in the same `namespace app`. No line in the sample calls either function, passes that config anywhere, or names the runtime object that collects them, so how the two are bound to a running application stays outside the quick start. Design documents are the obvious place to look, and finding the right one takes effort: 13 of the 17 files linked under Docs carry Chinese filenames, including the ones covering state, events and layout. Only four are English, among them `docs/DSL.md` and `docs/Shadertoy.md`.

Vendored or packaged, and the naming tax on both

A packaged SDK takes the same three lines as the vendored path, with no `cmake_minimum_required` and no standard flags:

find_package(EuiNeo CONFIG REQUIRED)
add_executable(my_app main.cpp)
eui_neo_configure_app(my_app)

Vendoring through `add_subdirectory(3rd/EUI-NEO)` compiles the framework from source inside your tree, so its build time and its options become yours to manage, while `find_package` hands both to whoever produced the SDK. One function serves the two paths, which is the point of the design. The tax is naming, because five spellings exist for a single thing. The repository and its directory are `EUI-NEO`, the CMake package is `EuiNeo`, the linked target is `eui::neo`, the wiring function is `eui_neo_configure_app()`, and the entry header is `eui_neo.h`. On a case-sensitive filesystem the two integration paths never meet, because one addresses the project as a folder and the other as a package.

A layout listing that leaves out two directories and one dependency

The Project Layout block names ten directories, and the repository root holds two more it never mentions: `scripts/` and `site/`. A reader mapping the tree will also see `apps/`, which holds longer or multi-page applications with each app in its own folder, sitting next to `examples/`, which holds short single-screen API demonstrations. Eight of the listed example files are C++ sources, and one of them is `examples/ffmpeg_video_player.cpp`, which comes with its own notes file. FFmpeg appears nowhere in the requirements, and those requirements name CMake, a compiler and OpenGL development files and nothing else, so the single example carrying a media dependency is also the one whose prerequisites are unwritten. Optional feature modules live under `modules/`, and `assets/` holds the runtime fonts, PNG, SVG and icons that the application never names explicitly. EUI-NEO's own source is under the Apache License 2.0, while vendored code under `3rd/`, dependencies CMake fetches at build time and bundled fonts under `assets/` keep their upstream terms.

Editorial conclusion

Take EUI-NEO when you already ship native C++ and want a functional DSL over GLFW or SDL2 windows and OpenGL or Vulkan drawing without choosing a widget stack by hand. Pass on it when onboarding has to be self-serve, because the clone step is empty, the backend switches sit in a Chinese-named guide, and the sample never shows how `compose` gets bound. Before adopting, build the `compose` sample against the SDK you actually received and confirm that `find_package(EuiNeo CONFIG REQUIRED)` resolves on your filesystem.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sudoevolve/EUI-NEO on GitHub