I think there still no C++ bindings for lvgl 9.x
I created this C++20 wrapper for lvgl
Everything compiles with 2 demos working (ebike and smartwatch)
Please be free to share feedback about it and the design decisions.
I used C++20 because of many useful features and with zero-cost abstraction in mind.
It’s so great to see! I’d really love to see a good C++ binding finally.
My only concern is maintainability. In order to easily follow LVGL API change we should generate the binding at least for the widgets. What do you think about it?
Thanks !
I can work on updating the API on each LVGL release. So each new lv release will support the newer API. I think it’s easier and more direct than generating a bindings then generating code from that binding. The biggest work was already made on the architecture, which is now complete. Following changes and adding functions here and there is easy.
If someone spots anything lacking, I can add it very fast.
Please note that one of the decisions I took is to decay the C++ API into generating the same binary as if someone is directly using the C API. In order to not add additional problems and overhead by the new wrapper. If something works in C, it will in C++.
I’ve also finished a C++20 wrapper based on work from vpaeder. See Yet a CPP port also being supported by lv_port_pc_vscode.
It supports (allmost) all widgets too and can be build using lv_port_pc_vscode. See GitHub - KimBP/lv_port_pc_vscode at lvglpp-lvgl9.3
It hasn’t been updated in 4+ years.
Right, vpaeder has closed development, but on my Git account I’ve continued the work and ported it to lvgl 9.3 so far. See my linked post
OK but your repo is specifically a plugin for vs code and isn’t really a standalone C++ wrapper. correct?
What do you mean by plug in for vscode?
I’ve used a slightly updated version of vpaeder 8.3 version for a large embedded project based on Zephyr RTOS.
While deciding to port to 9.3 I wanted to ensure all samples made by vpaeder could be verifyed, and therefore I used the lv_port_pc_vscode project as base.
Oh that’s where vscode comes from. Are there more lv-ports?
I’ve just focused on lvglpp which ought be agnostic to development tools and platform
OK, I see that you updated the old c++ port, but I am not sure it has everything lvgl can do.
In my port, everything the C library can do is supported by the C++ wrapper, which disappear on compilation (zero-overhead), this means that it itself doesn’t add new errors or edge cases to the state of the original C library.
For the C++20, it’s not just a random selection, I use C++ concepts for example that can catch non supported callback uses for example that diverge from what C library support.
I’ll have a look at your wrapper. Would be nice with just one being kept alive.
The vpaeder variant is zero overhead too I’d say. Only problem is a pointer to the real lvgl object which you sometime have to release ownership of, so it doesn’t get destructed when your cpp object destroys
This is a timely discussion which I’m happy to find. I also have a new C++ API targeting LVGL 9.4 here: GitHub - pedapudi/lvgl_cpp
The primary focus is on an updated API following idiomatic C++20 with strong typing, modularity, discoverability, and memory safety (including respecting LVGL’s preferred management of objects). Ultimately, code is ready by humans, and the goal is to make it easy and fast to develop with LVGL. The API design without many “gotchas” to get things running smoothly is the objective. Making choices so that creature comforts like turnkey benchmarking and design choices that jive with modern IDEs help with that goal.
The library also provides full interoperability with LVGL’s C-based APIs and objects. There is memory overhead benchmarking with pprof for analysis and ASan for cross-checks. The design/ directory contains running notes of the approach as the library heads towards a seminal release version. I’m auditing the API coverage and nearly all user-facing APIs (and enums) are covered. I have a few more rounds of contributions planned to improve coverage and reduce redundancy in the implementation.
The two variants of “hello, world” examples illustrate the improved ergonomics of this API. Besides managing the screen trees, managing more complex interactions with inputs and animations is significantly more modern.
With ESP32 boards as targets of the examples, I’ve naturally been using this library with ESP-IDF. The quantified memory and performance overhead is quite manageable on these boards so far. Should the need arise, there’s an opportunity for an optimization utility where the C++ representation is translated into isomorphic C to eliminate all overhead.
On the topic of maintainability and keeping the C++ implementation up to date: I haven’t tackled an approach to this that is truly automated, and it’s unclear to me if any idiomatic C++ API can be distilled to pure bindings (eg., SWIG). Codegen approaches can be leveraged as long as there is backwards compatibility in newer LVGL releases, but for novel LVGL APIs, updating the C++ implementation likely needs maintainer intervention. I intend to add some codegen tools for easily updating this C++ wrapper for new version updates.