When I developed my first LVGL project it was extremely odd to see that configuration is done with header files (abnormal) instead of using public APIs. Embedded Linux developers aren’t used to using header files for configuration. They are used to using public APIs for handling configuration instead without messing around with header files, which is just asking for trouble. Fiddling around with header files should be considered a big red flag.
AFAIK Linux-like projects typically uses Kconfig (menuconfig) which is supported by LVGL too.
In lv_conf.h you can configure build-time settings that wouldn’t be possible in runtime. But maybe I misunderstood something. Can you show an example from Linux-world for what you meant?
Just to clarify I was referring to Linux User Space applications (high level), which are different from Linux Kernel applications (system level). With User Space applications Kconfig wouldn’t be applicable.
I still don’t get it. Please mention one or more configs from lv_conf.h the can be or should be replaced by runtime API calls.
There are some configuration settings like LV_USE_GPU_NXP_PXP that aren’t applicable to the Linux Frame Buffer backend for example, which doesn’t make any sense to have as configuration when that backend is used. Backend configuration APIs are missing. It is a bit of a pain having to fiddle around with some header files to get the LVGL library to compile via CMake. It should be possible to do ALL configuration during runtime, and leave it up to the Software Developer to decide how to handle program configuration.
Right now it is a bit of a maze figuring out which configuration settings are relevant to the backend used by the program. It is much worse when looking at the LV Drivers library configuration (via lv_drv_conf.h) since there are a boat load of settings that aren’t applicable to the Linux Frame Buffer backend.
E.g. LV_USE_GPU_NXP_PXP needs to disabled on all platforms to exclude NXP specific function calls.
So it must be a compile time config.
We have started to work on restructuring the drivers. If you have some ideas to share, please comment on the linked issue.