I would like to upstream my crates

[SakiiCode]

Hi,

Over the last couple of months I have been working on lv_bevy_ecs, and lightvgl-sys as new Rust bindings for LVGL. The main difference is that it uses the Entity-Component-System framework of the Bevy game engine, meaning it solves the memory and lifetime issues outlined in #140 and #111.

It is originally based on code from this repo, however a lot of things have been rewritten:

• Lifetimes are intuitive with the owned Widget and borrowed Wdg, much like CString and CStr
• lv_codegen now autogenerates nearly every widget-related function (..._get_text functions not available #162)
• The raw bindings generation in lightvgl-sys has been separated (Move lvgl-sys to a separate repository. #176) and simplified as much as possible, to make it easy to use in any project. It also supports LVGL 9.4 (bump to LVGL 9? #195)
• Got rid of the object oriented approach that does not work in Rust and caused most of the difficulties here
• Styles, animations, events, observers, subjects, timers, logging and much more modules work out of the box
• Documentation is copied over to the safe functions
• The automated CI test has been ported completely
• Cross compile (Cross compile fixes #153) works and there is an example project
• And more...

The reason I'm opening this issue is that I think all of the ECS-unrelated code could be upstreamed into this repo. That way this repo would be storage-agnostic, and people could use any preferred storage solution. Also lightvgl-sys could be 1:1 transferred into lvgl-sys then more people would find it on crates.io.

If there is interest, I would have the capacity to maintain this repo and help developing the remaining features. As I spent lots of time experimenting and optimizing the new code, I would appreciate if upstreaming it would be an all-or-nothing PR.

Thanks for reading this and let me know what you think.

cc @kisvegabor

[goyox86]

Disclaimer: Not trying to throw shade to anyone here in LGVL. Here are my two nanocents @SakiiCode .

Been lurking, watching this repository for at least 2 years now and I have seen zero to no activity nor any type of response to people asking if this project is abandoned or what are the plans for it. I think the team really has little time to cover the Rust side and that is perfectly fine (companies have priorities!) but the radio silence is not a great sign. I had high hopes when I saw the original author moving it under the LGVL org few years ago umbrella but things have been very quiet.

I think its amazing and that is the best thing on open source, trying to avoid forks and contribute to what already exists! You are trying to do what would be the best for the ecosystem @SakiiCode, proposing donating the non ECS code and the improvements you have been doing on your crates (as well as your time as a maintainer for this repo).

All that being said, I (sadly have to admit) think you inserting this repo/project in your workflow or depending on it or in any capacity would end up hampering your ability to make progress. It seriously looks like a barren desert around here.

Anyways great work on lv_bevy_ecs, and lightvgl-sys!

[SakiiCode]

Thanks a lot for the nice feedback @goyox86. The problem is I don't want to force people to use an ECS, on embedded it hugely increases the binary size and needs more technical knowledge. However as you mentioned, splitting lv_bevy_ecs would further increase complexity for no real benefit.

Probably the "no_ecs" feature flag will be the good middle ground for a while :(

[goyox86]

More unsolicited advice 😅 on not forcing people to use ECS. Many great OSS projects started as people scratching their own itch being unapologetic about their choices, its a tool for themselves at the end of the day! Don't feel you are forcing people to use ECS and under any obligation of maintaining an OOP version of your library just because you are buildling what you need/like. You are just building your own thing, in your own free time and giving for free to the world. I can't tell you whether maintaining the no_ecs feature is worth the effort for you. I am not in your shoes, It is very nice of you to be this considered though!

More on the technical side (I am 100% sure you know this but anyways) there are very good reasons on why ECS is used in Rust for game development, at least why Bevy seems to work well. Rust ownership and borrowing principles change the way we program, ownership is more like a tree instead of a graph. The classic OOP approach with graphs of objects with ownership relationships going in all directions is not very easy to express in Rust. If you think about it, when you are trying to build a good high level library binding for a given language it ideally has to embrace idioms, best practices, of the language, obviously within the constraints imposed by the original library being wrapped.

BTW If you build something good we will use it regardless if it is ECS or not!

If it was up to me I would make it as Rusty as possible 😉 . A well maintained -sys low level crate just like you did should enable other people to to a more OOPy binding anyways.

Happy hacking!