In case this may help. We implemented an alternative RUST binding fir LVGL-V8, with:
- simpler memory management
- hight level API to abstract some of LVGL complexity
- LVGL+Driver C code independent from Cargo with the cross compilation remaining under cmake control
- we currently use this Rust model in development with Lvgl/GTK emulator and on our target (Arm based) with a touch screen and Linux frame buffer.
- while we implemented all core widgets we did not need and thus did not implement all LVGL features.
Our initial motivation was to enable the control of our LVGL-GUI by event from outside of the graphic module. Having one crate for graphic layout with an independent crate for the business logic. Because of chosen memory model current Rust implementation fails to support this type of configuration.
That’s fantastic news!
As a maintainer, I’m really interested in this development. I wonder if we can channel these great updates into our current Rust binding. Bringing together talented individuals to focus on a unified project can often lead to more effective and innovative results. Of course, I understand if your methodologies differ significantly. Still, it might be beneficial to open an issue for discussion. Exploring potential synergies could be very valuable for the LVGL community.
@kisvegabor forking is unfortunately far easier than merging. The good news is that we are still in a POC mode and will not attack production mode before best case mid-2024. As a result we still have room for radical API move.
In the main differences I can see from both approach:
- we choose to compile lvgl+driver outside of RUST, which significantly simplify the build process, this especially in complex cross environment.
- we target production and each dependencies have to be justified & documented. We have 4 time less dependencies (5 vs 30 with cargo-sbom). One of the reason is that we kept all low interfaces in C and reserve Rust to high-level api. (we do not see any value to redo in Rust what Lvgl/C already does)
- memory model, we stick to LVGL/C memory model with static allocation and did not try to implement any smarter model. We target only embedded Linux and did not try to make our code compatible with RTOS/MCU. In our model we cannot create dynamic widget that should be later destroy. We do not see this as a limit for the embedded world, but it is a clear limit of our model
- complexity: 6000 lines of Rust vs 2400. When you have to maintain a code for 15 years each line as a cost.
This being said the only show stopper that initially prevent us from using your code is the memory model. You make the assumption that GUI code will never return and will remain lock in to your mainloop, allowing Rust not to delete the object. We use an asynchronous model where the code doing the graphic composition should return a handle that hold the full graphic composition (screen widgets, …). The interaction with the graphic comes from external events (mainly sensors running in external micro-services). We keep a clear separation in between the graphic design and the business logic. Both are under the responsibility of two different developers and should remain as loosely couple as possible. This is why we use a simple “uid:&str” to link both world.
Conclusion: I do not see any major difficulty for us to shift to your widget API model, even if the fact you merge LVGL/C config into cargo/Rust tooling is going to be very hard to justify/document. As said before the only hard show stopper we see, is the main-loop model that for us should be kept independent of the graphic. Everything else is something negotiable event if you still have to many not critical dependencies that should be revisited before pretending to comply with long term support constrains.
The simplest way is probably for you to run our test code, this hopefully will provide you with a high level vision of two approach differences.
Thank you for the insight!
Actually I’m not one of the developer of the LVGL’s current Rust binding. I’m not even a Rust developer, so I cannot comment anything useful about the technical questions.
I still encourage you to open an issue here to discuss to possibilities with the related developers. If you do so, please tag me, so that I can also follow how the discussion goes.