LiTheView is now public: a C++ graphics library and VS Code designer for embedded applications

I originally developed LiTheView in the early 2010s. I wanted the familiar experience of building forms with MFC—placing controls, setting properties, and connecting event handlers—but in a graphics library suited to embedded systems.

Recently, I’ve been refreshing that work with modern C++23, a visual designer integrated into VS Code, and a workflow that lets the same application logic and UI run on Windows and embedded hardware.

That refreshed project is now public on GitHub.

The idea is straightforward: bring the familiar experience of a visual form designer to embedded C++, while keeping the developer in control of their application, hardware, and memory budget.

If you remember building forms with MFC—or have used C# visual designers—the workflow should feel familiar. Place controls, edit their properties, generate the UI code, and connect named event handlers to your application.

The embedded part changes the requirements. Display dimensions, pixel formats, memory capacity, and input devices all matter.

The foreground board view is a Windows simulator using a board photograph. Behind it is the same form open in the LiTheView designer.

Your application stays in charge

LiTheView is a component of your project. It doesn’t become your IDE or dictate your source tree.

For example:

MyControlPanel/
├── CMakeLists.txt
├── CMakePresets.json
├── Devices/
│   ├── Display/
│   ├── Touch/
│   └── Sensors/
├── Middlewares/
│   └── Third_Party/
│       └── LiTheView/
├── Tasks/
│   └── UI/
│       ├── forms/
│       ├── Generated/
│       └── form_handlers.hpp
└── Platform/
    ├── Windows/
    └── STM32/

Prefer externals/LiTheView or UI/LiTheView? Those layouts work too.

You open your application in VS Code. The designer edits forms and generates portable C++ components. Your existing CMake presets build the application, and your existing debugger launches it. Handwritten application behavior stays separate from generated files.

Develop on the PC, then connect the hardware

The supplied STM32H750 starter demonstrates the model:

1. Define the display’s dimensions, native storage format, and logical input.
2. Design a form in VS Code.
3. Generate its C++ component and connect the handlers.
4. Build and debug the Windows application.
5. Build the STM32 target using the same application logic and generated UI.

The platform implementations change. On Windows, mouse input can represent touch, and a clickable region on a device photograph can represent a physical button. On the board, the corresponding drivers supply those events.

The H750 example also runs FreeRTOS on Windows, so the simulator exercises the shared application task structure.

Render for the display you actually have

A small embedded display shouldn’t automatically require a large RGB framebuffer followed by conversion on every update.

LiTheView supports native rendering formats, including RGB565, XRGB8888, and packed low-bit-depth formats. The selected configuration determines the rendering representation. Display compatibility and target resource budgets are separate checks: you can develop a valid UI before choosing the MCU or receiving the hardware.

The core is C++23 and has no STM32 HAL, FreeRTOS, Win32, or .NET dependency. Those belong to the application platforms or development tools.

This is still an evolving project. The current examples, tests, and documentation establish the supported workflows; broader hardware coverage and additional examples will grow from practical use cases.

The project is available under GPLv3.

👉 Explore LiTheView on GitHub

👉 Start with the setup guide

I’d especially welcome feedback from developers building custom control panels: what makes the transition from a desktop simulation to your embedded hardware difficult today?