# eepp (Entropia Engine++) review: a C++ UI framework for native apps and games > eepp is an MIT-licensed C++ framework that puts a CSS-styled, XML-described widget system on top of an OpenGL renderer. It suits teams building desktop or mobile tools with a custom interface, and it asks for a source build in return. **SpartanJ/eepp** — eepp is an open source cross-platform game and application development framework heavily focused on the development of rich graphical user interfaces. - Repository: https://github.com/SpartanJ/eepp - Website: https://eepp.ensoft.dev - Stars: 625 · Forks: 53 - Language: C++ - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/spartanj-eepp ## What eepp solves, and who is expected to use it Most C++ application frameworks give you a window and a renderer and leave the interface to you. eepp goes the other way. The README describes it as a cross-platform game and application development framework heavily focused on the development of rich graphical user interfaces, and the feature list backs that up: a widget set, a layout system, themes, CSS styling, XML layout loading, and a node-based scene graph that the widgets sit on. The intended user is a C++ developer building something where the interface is not a form over a database but the main surface: a level editor, an asset tool, a kiosk application, a game with dense menus. The framework covers the layers below the UI too, so the same binary can own the window, the audio, the resource loading and the rendering. That is the trade-off. You get one dependency instead of six, and you accept eepp's opinions about how a scene, a node and a widget relate. It is not a drop-in replacement for a retained-mode desktop toolkit, and it is not a game engine with a scene format you can hand to a designer. The README is explicit that the map editor lacks several features and may be abandoned in favor of TMX map support, which tells you where the author's attention sits. ## How the UI module, renderer and scene graph fit together The architecture is layered, and the layering is visible in the module list. At the bottom, the window module is backend based, with SDL 2 as the only backend listed. Above it, the graphics module provides renderers for OpenGL 2 fixed pipeline, OpenGL 3 programmable pipeline, OpenGL ES 1 and 2, and OpenGL Core Profile, plus a batch renderer that the README says batches all rendering automatically. The scene module is a node-based system with an event system and a node message system, and the UI module builds widgets on top of those nodes. That is why the README can claim all basic input interaction events (clicks, keypress, mouse over, focus) as a widget-level feature: they are node events routed through the scene graph. Programmable actions for nodes (fade, rotate, move, scale) are the animation layer, and the UI module adds animation support, scaling, rotating and clipping on top. Two details matter more than they look. Draw invalidation means the framework only redraws when something changes, which the README frames as the reason it can be used to make real apps with low resource usage. And the layout system is described as similar to Android layouts, with LinearLayout, RelativeLayout and GridLayout. If you have written Android XML layouts, the mental model transfers almost directly, down to loading layouts from XML and styling them with Cascading Style Sheets. The HTML and CSS compatibility layer is a separate effort inside the same module. It renders HTML natively through a UIWebView component, and UIMarkdownView uses it for Markdown. The CSS layout coverage listed includes block, inline, inline-block, flex, inline-flex, grid, inline-grid, table, list-item and none display modes, with absolute, fixed, float, relative and sticky positioning. The README calls this an ongoing effort and says it follows the specifications rather than custom behavior, which is a claim about intent, not a statement of completeness. ## Building eepp from source with premake The repository has no install section in the README. What it does have at the top level is premake4.lua, premake5.lua, a premake/ directory, and projects/, which is the layout you expect from a project that generates its build files. The documentation is hosted separately and the README points readers to src/examples for code, with src/test and src/tools as further references. The shape of a source build is therefore: clone the repository, generate project files with premake, build, then read the examples. The commands below follow that layout. Substitute your own generator if you are not on Linux, since the README lists official support for Linux, Windows, macOS, FreeBSD, Haiku, Android and iOS. ```bash git clone https://github.com/SpartanJ/eepp.git cd eepp git submodule update --init --recursive ``` The submodule step matters because the repository contains a .gitmodules file, and the window module depends on SDL 2 as its backend. Skipping it leaves the window layer without its dependency. ```bash premake5 gmake2 make ``` premake5.lua is the generator script. Running it produces the makefiles, and make builds the library and the tools. The README does not document the resulting artifact paths, so check what the generator emits for your platform rather than assuming an install prefix. For a first real use, the README directs you to src/examples. That is the honest starting point: the documentation is described as roughly 50 percent complete, so an example that opens a window, creates a UI node and loads a layout from XML tells you more about the intended API than the docs currently do. The tools in src/tools are the second reference, and the UI Editor is the one worth opening first, since the README describes it as loading layouts from an XML file and showing changes in real time. ## Where eepp will cost you time: documentation, releases and optional modules The README states plainly that about 50 percent of the project is documented and that the UI module, described as the most important and complex module, lacks proper documentation. That is the single largest cost of adoption. You will be reading headers in include/ and examples in src/examples to answer questions the documentation does not. The release situation is the second issue. The most recent release listed is a nightly build of ecode dated 2024-09-29, and the last push to the repository was on 2024-09-29. There is no tagged stable release line in the repository. If your process requires versioned upstream releases with changelogs, this project does not currently offer them, and you should plan to pin a commit rather than a version number. The optional modules deserve a look before you commit. Physics is a chipmunk wrapper, and the maps module is Tiled maps with software dynamic lights plus a map editor. The README says the map editor lacks several features and will probably die in favor of TMX map support, with no decision made at the time of writing. Building a pipeline on that editor is a bet against the author's own stated direction. Finally, the window module supports SDL 2 as its backend and the README frames the module as backend based, meaning other backends are possible. Possible is not the same as present. If you need a windowing path that is not SDL 2, you are writing it. ## eepp compared with Qt Quick and Dear ImGui The closest comparison in intent is Qt Quick, which also pairs a declarative UI description with a C++ core and a scene graph renderer. The difference is in the description language and the licensing posture. Qt Quick uses QML, a JavaScript-like language with its own runtime, and Qt ships under a dual commercial and open source arrangement with obligations that vary by module. eepp uses XML for layout and CSS for styling, both of which are declarative markup rather than a programming language, and the whole repository is MIT. If your team already knows CSS and XML, eepp's learning curve is shorter. If you need a large ecosystem of third-party components, Qt has no equivalent here. The other comparison is Dear ImGui, the immediate-mode library common in game tooling. Dear ImGui has no retained widget tree, no layout system, no CSS and no XML. You call it every frame and it draws. eepp is the opposite: a retained node tree with events, focus, themes and draw invalidation. Immediate mode is faster to start with for a debug overlay and worse for a complex, styled, event-driven application. eepp's draw invalidation only pays off because the tree is retained; there is nothing to invalidate in an immediate-mode UI. A third reference point is the framework's own Virtual File System, which the README compares to PhysicsFS for abstracting zip files and the local file system into one. That comparison is about a subsystem, not the whole project, but it is a useful signal: eepp reimplements pieces that C++ projects often take from small dedicated libraries. ## Licence, maintenance and the cost of upgrading The repository is MIT licensed, with LICENSE at the top level. MIT is permissive: it allows use in closed-source products and requires that the copyright notice and permission notice be included. That is a summary of the licence text, not legal advice, and the obligations of any dependency you link against are separate from eepp's own terms. The network module is a case in point: the README says TLS support is provided by mbedtls or openssl, and both carry their own licences that you need to check against your distribution model. On maintenance, the last push was on 2024-09-29. There is no archived flag on the repository, but a gap of that length means you should treat the codebase as something you may need to patch yourself. The upgrade cost follows from the missing release line. Without tags, an upgrade means diffing commits between the commit you pinned and a newer one, then rebuilding through premake5.lua and rechecking the examples that your code was modeled on, because examples move when the API moves. Vendoring the source into your own tree and building it as part of your project is the pattern the repository layout supports, since the build is generated rather than installed. ## Conclusion Adopt eepp if you are writing a C++ desktop or mobile application whose interface is the product, you are willing to build from source with premake, and you can work from the examples in src/examples because roughly half the project is documented. Do not adopt it if you need a stable tagged release line, a documented API for every module, or a UI toolkit with a large third-party component ecosystem. Before committing, verify the following: that premake5.lua generates a working project for your target platform, that the modules you need (physics, maps, network) are the optional ones you actually want, and that the UI module documentation covers the widgets you plan to use, since the README states the UI module is the most important and complex part and lacks proper documentation. ## FAQ ### What is eepp used for? eepp is a cross-platform game and application development framework focused on building rich graphical user interfaces. It provides a widget system with CSS styling and XML layouts on top of an OpenGL renderer, and it also covers audio, networking, scenes and resources. ### How do I build eepp from source? Clone the repository, initialize its submodules, then run premake5 to generate build files and build the result. The README does not give install steps, but the top-level premake4.lua, premake5.lua and premake/ directory show that premake drives the build, and src/examples holds the code to start from. ### Which platforms does eepp support? The README lists official support for Linux, Windows, macOS, FreeBSD, Haiku, Android and iOS, and says it exports to HTML5 using emscripten with some minor limitations. Window and input handling currently use SDL 2 as the backend. ### Is eepp free to use in a commercial product? The repository is MIT licensed, which permits use in closed-source products provided the copyright and permission notice are included. Dependencies such as mbedtls or openssl, which the README names for TLS support, carry their own terms. ## Sources - [Official documentation](https://eepp.ensoft.dev) - [Official README](https://github.com/SpartanJ/eepp#readme) - [Project repository](https://github.com/SpartanJ/eepp) - [Release notes](https://github.com/SpartanJ/eepp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spartanj-eepp