You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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.
Few lesson learn from of lvgl/rust work:
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.
The text was updated successfully, but these errors were encountered: