Lopaka for generating embedded display graphics in C and C++

Lopaka's embedded graphics workflow

Lopaka addresses a specific gap between visual design and embedded firmware. Creating a readable status screen for a microcontroller often means translating every rectangle, icon, line, and label into low-level drawing calls while respecting a fixed screen size. Lopaka moves that work into a pixel-oriented editor and then emits C or C++ for the selected graphics platform.

The intended audience is visible in the README: embedded engineers, GUI designers, and people building Arduino projects. It specifically mentions Arduino, ESP32, and STM32 projects. Supported targets include TFT_eSPI, u8g2, AdafruitGFX, Flipper Zero, Inkplate, and Watchy. Compatibility is also stated for M5GFX, LovyanGFX, and other libraries. ESPHome is listed as coming soon, so it should not be treated as an implemented target.

This is not a general image editor with firmware as an optional export. Its feature set is centered on constrained displays: configurable screen sizes, a zoom scale, pixel-perfect editing, movable and resizable elements, shapes, supported fonts, and custom images. XBMP generation is included for bitmap-oriented workflows. That focus makes the tool more relevant to dashboards, device menus, badges, and compact instrument interfaces than to illustrations that need continuous tones or arbitrary typography.

The trade-off is equally clear. Lopaka handles visual arrangement and code generation, while the generated source still has to become part of an embedded program. The README does not document firmware integration helpers, automatic library installation, or a complete deployment path from the editor to a running device. A successful export therefore means that source code has been produced, not necessarily that the display is already connected or running.

Vue, Vite, and target-specific code generation

The application is built with Vue 3 and Vite. The repository layout contains source configuration, styles, public assets, fonts, images, tests, and Vite plugins. Its package metadata describes it as an "Embedded graphics editor with code builder," which matches the documented workflow of drawing a design and producing source code.

The generation target is central to that workflow. Lopaka does not present one universal drawing dialect as the only result. Its supported-platform list includes TFT_eSPI, u8g2, AdafruitGFX, and Flipper Zero, while the feature list explicitly identifies C/C++ output and XBMP graphics. This indicates a target-aware builder rather than a basic image exporter, although the README does not document the internal generator architecture or show a generated code sample.

Custom images are supported, but import and conversion are not explained in enough detail to establish accepted file formats, color handling, transparency rules, or memory treatment. The package file includes image-related JavaScript dependencies such as `gifuct-js`, `base64-arraybuffer`, `pako`, and `truetype2gf`, but dependency names do not establish the behavior users should expect. A project evaluating Lopaka should inspect a real export before committing artwork with transparency, animation, or many colors.

Flipper Zero live preview is the most specific device feedback feature in the README. That can shorten the distance between an editor layout and its hardware appearance, but the documentation does not explain connection requirements, preview latency, or whether generated Flipper code is ready to flash without further work. Live preview should not be confused with a general deployment system for arbitrary Arduino boards.

Running Lopaka with Docker Compose

The repository provides a Docker Compose path that builds the application and exposes it through nginx. This is the most self-contained documented option because the `Dockerfile` installs dependencies, runs the production build, copies only `/app/dist` into the nginx image, and exposes port 80. The Compose file maps the container service to host port 80.

Run the documented command from the repository root:

docker-compose up --build

The build uses `node:22.3.0-alpine` for the application stage and `nginx:alpine-slim` for the served production files. During the build, the container runs `pnpm install --frozen-lockfile` and then `pnpm build`. Once the containers start, the service is available through the Compose mapping on port 80. The README does not state the browser URL convention, so this article does not assume one.

The Compose configuration names the image `woomoo/lopaka`. That is a build and deployment detail, not an independent description of the upstream license or an indication that the container is the only distribution channel. Lopaka also has a hosted cloud deployment at `https://lopaka.app`, described by the README as a fork deployed through Cloudflare Pages.

For a private or local instance, container startup is concise. The operational consequence is that nginx serves static files rather than a documented backend API. The repository files do not describe persistent storage, authentication, design synchronization, backup procedures, or database configuration for a self-hosted installation. Those topics require verification before a production deployment.

Local pnpm development and production builds

For contributors or developers who prefer a local Node.js setup, the README requires pnpm to be installed first. The documented installation command is:

pnpm install

That command resolves the dependencies recorded by the repository. The project includes `pnpm-lock.yaml`, while the Docker build uses the stricter form below to reproduce the locked dependency graph:

pnpm install --frozen-lockfile

After installation, the development script starts Vite:

pnpm dev

The development server is intended for editing the Vue application locally. The README does not document its default host or port, so neither should be added to a project guide without inspecting the local Vite output.

A production build uses the package script that builds the documentation before building the application:

pnpm build

According to `package.json`, that script expands to `vitepress build pages && vite build`. This detail matters because a production build is not just a single Vite invocation. It also depends on the documentation files being present in the expected location. The Docker build supplies `NODE_OPTIONS="--max-old-space-size=16384"`, which indicates that the container build allows additional Node.js heap memory.

For a first real use, start either the development server or the Compose service, then create a small design using the documented tools: choose a screen size, draw a few basic elements, add text with a supported font, and inspect the generated C or C++ for the selected target. The README does not give exact menu names, so the expected observable result is the editor itself plus generated code, not a particular sequence of button clicks.

WebMCP editing and its control boundary

Lopaka adds WebMCP support for compatible AI assistants. According to the README, an assistant can inspect the screen and generated code, create and edit layers, arrange them, place built-in icons or already imported images, and change screen settings. These are design operations, so the assistant acts through a structured interface rather than merely discussing code in a chat window.

The documentation places the user in control of the result. That distinction matters for embedded graphics, where an apparently minor change to dimensions, font settings, or image placement can alter generated source. WebMCP does not say that an assistant can flash firmware, install libraries, compile a sketch, or verify output on a physical display. Those tasks remain outside the documented feature boundary.

WebMCP also depends on compatibility between the chosen assistant and Lopaka. The README does not name a required client, explain connection setup, document supported natural-language commands, or state whether every editor action is exposed. The package metadata includes Supabase and PostHog JavaScript packages, but their presence does not establish which WebMCP or cloud functions are available in a self-hosted deployment.

For adoption, WebMCP is most relevant to users who want an assistant to perform repetitive layout operations while retaining visual review. It should not be evaluated as an autonomous firmware agent. The first check should be whether the compatible assistant can inspect and modify a local design without changing the selected screen dimensions or target library unexpectedly.

Constraints, maintenance, and hand-coded alternatives

The clearest limitation is portability. Lopaka is useful when the display stack is represented by a supported platform or a stated compatible library. A project with a proprietary rendering layer, unusual pixel format, or unsupported MCU toolchain may be unable to use the generated output. The documentation does not promise arbitrary code backends, and ESPHome remains marked as coming soon.

Embedded constraints add another verification burden. Screen dimensions, font availability, flash storage, RAM, processing time, and image encoding all matter after code generation. The README does not report generated-code size, memory use, compilation behavior, or performance results. It also does not document rollback, project files, collaboration, versioned exports, or automatic firmware updates. These omissions do not prove the features are absent, but they are not documented guarantees.

The most direct alternative is to hand-write draw calls using TFT_eSPI, u8g2, or AdafruitGFX. That approach gives the developer exact control over the firmware and avoids depending on a visual generator, but layout calculations, repeated drawing code, and text positioning are manual. Lopaka shifts that work into an editor and produces source code for the selected target. The choice is between visual iteration and direct control, not between one programming language and another.

Maintenance history is recent in the repository facts. The last push was on 2026-10-16, and the repository is not archived. Recent releases include version 0.6 on 2026-03-16, version 0.5 on 2025-02-25, and version 0.46 on 2024-03-22. The Apache-2.0 license permits use and modification under its terms, but users still need to review the actual `LICENSE` file and comply with its notices and conditions. Upgrade cost is primarily migration work: artwork may need to be recreated, exports rechecked, and generated source recompiled after a target or schema change. The documentation does not promise compatibility across Lopaka versions.

Editorial conclusion

Lopaka fits embedded developers and GUI designers who want to arrange small-screen graphics without manually calculating every draw call, as well as teams already targeting one of its supported libraries. It is a poor fit for unrestricted vector illustration, firmware automation, or projects requiring an unlisted display backend. Before adoption, generate a representative design and verify its dimensions, fonts, image format, library compatibility, memory use, and integration with the target MCU. Version 0.6 is the relevant documented release to evaluate first.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sbrin/lopaka on GitHub