LVGL codegen: optional nested object structs for repeated UI blocks

[Mep007]

I have an experimental fork that adds an optional LVGL codegen mode for projects with repeated UI blocks, such as dashboard tiles.

Fork/branch:
https://github.com/Mep007/EEZ_Studio/tree/mesp-lvgl-codegen

What it addresses:

• Current LVGL output uses one flat global objects namespace, so every referenced widget needs a globally unique identifier.
• Repeated containers with the same internal structure become awkward, because child widgets cannot reuse local names like icon, lbl, value, bar.
• The fork adds a build option: Nested object structs (experimental).
• When enabled, generated object references are grouped into nested C structs per screen/object hierarchy.
• Named widgets with children become struct nodes; the widget pointer is available as .obj.
• Default flat output remains unchanged unless the option is enabled.

Example intended access pattern:

objects.page_1.widg_3.icon
objects.page_1.widg_3.lbl
objects.page_1.widg_3.value
objects.page_1.widg_3.bar
objects.page_1.widg_3.scale

objects.page_1.widg_4.icon
objects.page_1.widg_4.lbl
objects.page_1.widg_4.value
objects.page_1.widg_4.bar
objects.page_1.widg_4.scale

[frankalicious]

I might be mistaken, but couldn't something similar already be implemented using user widgets?

typedef struct _objects_t {
    lv_obj_t *main;
    lv_obj_t *widget_1;
    lv_obj_t *widget_1__my_button;
    lv_obj_t *widget_1__my_label;
    lv_obj_t *widget_2;
    lv_obj_t *widget_2__my_button;
    lv_obj_t *widget_2__my_label;
} objects_t;

---

---

[Mep007]

Yes, user widgets can help with one specific reuse case, but the idea here is closer to the object model used by tools like TouchGFX.
The goal is that object names only need to be unique within their parent scope, not globally across the whole project.
For example, two repeated containers on the same page can both contain children named bar and scale:

objects.page_1.widg_3.bar
objects.page_1.widg_3.scale
objects.page_1.widg_4.bar
objects.page_1.widg_4.scale

And the same parent/child names can also be reused on different pages:

objects.page_1.widg_3.bar
objects.page_1.widg_3.scale
objects.page_2.widg_3.bar
objects.page_2.widg_3.scale

So this is not mainly about user-widget reuse. It is about generating a hierarchical C object structure that reflects the page/widget tree, where both parent and child names can be reused in different scopes.
The current generated model is still flat, even if names are prefixed. This proposal keeps the structure explicit in C instead of encoding hierarchy into long flat identifiers.