Derive all classes from lv_obj

[amirgon]

This issue continues the discussion we started on #18.

To summarise it:

lvgl provides C functions per class, including all functions of the class's parents, excluding lv_obj.
For example, btn class provides lv_btn_set_fit which calls internally to lv_cont_set_fit. Therefore there is no need to inherit classes according to class hierarchy. Instead, all classes should inherit directly from lv_obj.

[embeddedt]

lvgl provides C functions per class, including all functions of the class's parents, excluding lv_obj.

I will look into this; I think there are some functions that aren't passed down to the youngest object type.

[kisvegabor]

lvgl provides C functions per class, including all functions of the class's parents

Not exactly. Only to those functions which makes sense for the object. For example lv_sw doesn't need lv_slider_set_value therefore there is no lv_sw_set_value but lv_sw_on/off.

[amirgon]

Not exactly. Only to those functions which makes sense for the object. For example lv_sw doesn't need lv_slider_set_value therefore there is no lv_sw_set_value but lv_sw_on/off.

@kisvegabor You are right.
Do you agree that it still makes sense to derive all classes directly from lv_obj on (micro)python?

I think there are some functions that aren't passed down to the youngest object type.

@embeddedt In such case, maybe the best thing would be to add such (static inline) functions for the relevant classes.

[kisvegabor]

Do you agree that it still makes sense to derive all classes directly from lv_obj on (micro)python?

Yes, every object type should know the lv_obj_... functions. But they some of them might be overwritten by the derived objects. It's not implemented yet but it was asked a few times that how to disable "clicking" of a page (or ddlist, roller, text area etc). Now you have to do:

lv_obj_set_click(page, false);
lv_obj_set_click(lv_page_get_scrl(page), false);

It'd be nice to have lv_page/ta/ddlist/roller_set_click() to do it with one function. In this case, I suppose page.set_click should refer to lv_page_set_click instead of lv_obj_set_click.

[amirgon]

Done.

Closing.

[kisvegabor]

Awesome!

[amirgon]

@kisvegabor does this still stand for v8?

In Micropython on v6 and v7 we inherit all objects from the base lv_obj.
Originally I planned to implement full inheritance but found out that LVGL was not compatible with this.

But now, with revised LVGL inheritance on v8, should we keep the current inheritance model in Python, or move to full inheritance that follows LVGL class inheritance?

Here are the quotes for the rational behind inheriting everything from lv_obj and avoiding full inheritance:

Ah, that clarifies things. It would mean that in (Micro)Python, every object should inherit just from obj and not from any other object. That way, all functions that are not defined for that specific object, will not be present (i.e. there will be no my_kb.set_map(..) any more).

Doesn't that defeat the whole idea of inheritance? For example, why define both lv_cont_set_fit and lv_btn_set_fit that do the same thing instead of calling lv_cont_set_fit on a btn object which is a child of cont?

It makes things clearer. Without adding all parent functions to the child the user would need to use the ancestor's API functions which:

• makes the API more complicated (the user need to check the ancestor's functions too)
• the code itself becomes messy (E.g. using lv_obj_, lv_cont_ and lv_btn_ when creating a button)
• some ancestor function doesn't make sense with the derived object. E.g. switch is derived from slider. You could use lv_slider_set_value() but it doesn't make any sense for switch. Therefore switch has lv_sw_on/off which uses lv_slider_set_value.

[kisvegabor]

The new inheritance "model" is manly only an internal thing. The concept from the outside hasn't changed much. Therefore the 3 points from the quote still stand:

• makes the API more complicated (the user need to check the ancestor's functions too)
• the code itself becomes messy (E.g. using lv_obj_, lv_cont_ and lv_btn_ when creating a button)
• some ancestor function doesn't make sense with the derived object. E.g. switch is derived from slider. You could use lv_slider_set_value() but it doesn't make any sense for switch. Therefore switch has lv_sw_on/off which uses lv_slider_set_value.

So IMO this part should remain the same. Or do you see some optimization/improvement options?