-
Notifications
You must be signed in to change notification settings - Fork 82
Open
Description
After trying to use lv_binding_rust for almost two weeks, we finally gave up. We add two many memory issue and we came to the conclusion that fixing memory model would require more work than rewriting a new lvgl/rust binding based on simpler concepts. Note we are working in Cross environment, targeting a Arm platform in frame-buffer and or goal was to publish a simple UI for an EV-Charger, also we need only a subset of LVGL features/options.
- Our work is available at https://github.com/tux-evse/lvgl-rclib-rs * : feel free to take any idea you may find useful.
Few lesson learn from of lvgl/rust work:
- leaking widget memory structure is far simpler and match pretty well embedded constrains, where widget are usually static and not create on the fly.
- proposing a hight level API, somehow like Phyton does, make developer far simpler. It also simplyfy the binding as many method are common to all widget (ex: lock, border, size, ...)
- implementing a "super class" model for widget allow to manipulate any widget in a generic way without dealing with each specific flavour (Label, Button, ...). This is especially important when retrieving/sending event from en external mainloop.
- we choose to compile lvgl/C outside of lvgl/Rust project. This appear to us simpler for both development and LTS maintenance.
- Reducing dependencies: we have to maintain our code for 10-15 years and limiting external dependencies to the strict minimum is a MUST have feature.
LVGL is really a very cool library, and having a higher API model make easier for our graphic developer that are not C/C++ expert to development nice UI on embedded device.
rafaelcaricio, chiro2001, ruzko and C47D
Metadata
Metadata
Assignees
Labels
No labels