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