search

lvgl / lv_binding_cpp

[WIP] C++ binding for LVGL
MIT License
44 stars 20 forks source link

OS And thread interface #3

Closed fstuff-dev closed 3 years ago

fstuff-dev commented 3 years ago

We have now to define how to interface the library with different OS/RTOS and how to manage the LvApp Object.

kisvegabor commented 3 years ago

As you probably know lvgl pushed this task to the user to keep lvgl simpler. It means you need to take/release mutexes to protect LVGL related calls.

Can we start with such a simple approach, or do you have something in mind?

fstuff-dev commented 3 years ago

The problem with this approach is that LvApp is derived from LvThread that implement a std::thread interface. std::thread isn't avaiable on most RTOS for example freeRTOS. I think that we need to provide a simple OS interface. I can provide a simple interface that worked for me in past. But it's only my opinion. I'will upload in a separate branch so you can judge the code.

fstuff-dev commented 3 years ago

or we can simply let the user to implement the LvThread Class !?

kisvegabor commented 3 years ago

I can't see why we need LvApp in the binding. IMO we should leave the the inits in LvApp::Init to the user for higher flexibility.

What do you think?

fstuff-dev commented 3 years ago

LvApp class it's just a helper class for the user ... the user should only derive the class and create widgets.... i think that can be useful. Obviously it's Closed to the user and at moment don't let to setup different drivers than implemented drivers.

fstuff-dev commented 3 years ago

If the idea of LvApp doesn't like we can change it !

kisvegabor commented 3 years ago

I suggest starting with something minimal and add extra sugar when we have a stable base.

So I vote fore removing LvApp for now and focus on the binding itself.

fstuff-dev commented 3 years ago

Yep ... not a problem !