Alternative option for Rust/Lvgl binding

[fulup-bzh]

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.

[meowcakes]

Personally I've found it easier to just interface directly with the raw LVGL functions than to try to use this Rust wrapper

[C47D]

Personally I've found it easier to just interface directly with the raw LVGL functions than to try to use this Rust wrapper

@meowcakes Do you have any advice on how to improve this wrapper? We're starting to work on it again and me personally I'm working on this because I have interest in rust lang, so any advice is welcome

[meowcakes]

I think a lot of the issues I've faced are already captured in other issues, e.g. some of the issues I've encountered are
#166
#168
#163

Additionally a large number of functions are just missing from the wrapper, and the raw obj pointer is not public outside the crate so if you want to use those functions you are forced to use only lvgl_sys so might as well only use that everywhere and just deal with all your functions being unsafe. Also you are stuck on v8, I've just forked lvgl_sys so I can use v9 in my project.

I'm not sure what advice I can give other than my experience with using only raw LVGL via lvgl_sys is much more pleasant because of the aforementioned issues, even though everything in the GUI code becomes unsafe.

[C47D]

Hi, thanks again for taking some time to give us feedback, this repo went silent for a while and we're catching up.

---

We're currently discussing separating lvgl-sys into another repo so it can be updated when LVGL releases a new version (major, minor or patches), see the discussion here #176

---

I've added the issues you listed in this other issue #184 were we have some action points for this repo. And about the wrapper I've just opened a PR adding some methods/traits to Label and Textarea, do you mean that kind of wrappers? See #188 , I'm just getting familiar with Rust and this repo