Problem: Although LVGL, as the name states, is lightweight and versatile, this also comes at the expense of removing many high-level functionalities. This makes LVGL very unwieldy to use when coding and debugging (increasing the chance of making an error on mundane LVGL tasks, rather than on actual GUI functionality), as well as confusing to understand—in the context of a codebase—when used to tackle such a (relatively) large-scale problem (that is, having an all-in-one brain GUI; refer to #1).
Significance: While this barebones approach may seem to make LVGL look unusable, this low-level implementation also allows for vast flexibility and customization, which we can leverage with wrapper classes that build on top of LVGL functions.
Solution:Development of a solution to this issue has already started, but I would like to nevertheless lay out my goals for its implementation. As part of solving this issue, we should (including, but not limited to the following):
create a Screen class, that extends the functionality of LVGL screens by allowing for objects like buttons and sliders to be automatically created and appended to the screen.
one feature I would like to see in this Screen class is a customizable add_btn() function, that allows you to implement different types of buttons while starting from a pre-made template (one such type I am envisioning is a button template allowing you to switch between screens; all you have to do is pass in the Screen variable, representing the screen to switch to, when you create your button!) therefore, there will be a void parameter "type" that, if passed a nullptr, will revert to default button creation parameters (which will be made void so they are "technically" optional), ELSE, will follow type-specific creation; an example of which was mentioned above.
the Screen.get_parent() class seems a bit useless; see if you can refactor it out of the code
create an LVGLObj class (I don't like this name though; consider picking a different name (that isn't just "Object," to differentiate it from actual C++ objects)), that extends the functionality of normal LVGL objects by allowing for functionality such as adding labels to objects with one function call. In addition, Screen functions that normally would return lv_obj_t* variables should return LVGLObj instances instead
note that some current Screen functions may have to move to LVGLObj!
also note that object creation methods will be static class methods under LVGLObj (they will be called using the syntax LVGLObj::<function>(); and will return the object as an LVGLObj instance, just like normal LVGL functions would with the LVGL equivalent (lv_obj_t*)
note that, in addition to implementing the wrapper classes themselves, additional functions that need to be part of the wrapper classes may be specified and mentioned in the comments of this issue; they are all expected to be added before the issue is resolved
Problem: Although LVGL, as the name states, is lightweight and versatile, this also comes at the expense of removing many high-level functionalities. This makes LVGL very unwieldy to use when coding and debugging (increasing the chance of making an error on mundane LVGL tasks, rather than on actual GUI functionality), as well as confusing to understand—in the context of a codebase—when used to tackle such a (relatively) large-scale problem (that is, having an all-in-one brain GUI; refer to #1). Significance: While this barebones approach may seem to make LVGL look unusable, this low-level implementation also allows for vast flexibility and customization, which we can leverage with wrapper classes that build on top of LVGL functions. Solution: Development of a solution to this issue has already started, but I would like to nevertheless lay out my goals for its implementation. As part of solving this issue, we should (including, but not limited to the following):
Screenclass, that extends the functionality of LVGL screens by allowing for objects like buttons and sliders to be automatically created and appended to the screen.Screenclass is a customizableadd_btn()function, that allows you to implement different types of buttons while starting from a pre-made template (one such type I am envisioning is a button template allowing you to switch between screens; all you have to do is pass in theScreenvariable, representing the screen to switch to, when you create your button!) therefore, there will be a void parameter "type" that, if passed a nullptr, will revert to default button creation parameters (which will be made void so they are "technically" optional), ELSE, will follow type-specific creation; an example of which was mentioned above.Screen.get_parent()class seems a bit useless; see if you can refactor it out of the codeLVGLObjclass (I don't like this name though; consider picking a different name (that isn't just "Object," to differentiate it from actual C++ objects)), that extends the functionality of normal LVGL objects by allowing for functionality such as adding labels to objects with one function call. In addition,Screenfunctions that normally would returnlv_obj_t*variables should returnLVGLObjinstances insteadScreenfunctions may have to move toLVGLObj!LVGLObj(they will be called using the syntaxLVGLObj::<function>();and will return the object as an LVGLObj instance, just like normal LVGL functions would with the LVGL equivalent (lv_obj_t*)note that, in addition to implementing the wrapper classes themselves, additional functions that need to be part of the wrapper classes may be specified and mentioned in the comments of this issue; they are all expected to be added before the issue is resolved