Updated LVGL defs from 8.x to LVGL 9.x

[carylhubin]

This PR updates LVGL definitions and API references from version 8.x to 9.x

[carylhubin]

I noticed that this macro is used at the top of the files (lvgl + python):

#define LV_OBJ_T {obj_type}

typedef struct mp_lv_obj_type_t {
    const lv_obj_class_t *lv_obj_class;
    const mp_obj_type_t *mp_obj_type;
} mp_lv_obj_type_t;

I was wondering if it’s still necessary.

[carylhubin]

Inside gen/stub_gen.py, function def run(json_path, lvgl_api_json_path):,
argument lvgl_api_json_path is currently unused.

Is this still a work in progress?

[kdschlosser]

yes the stub generator is not finished. It has many issues that need to be hammered out.

[kdschlosser]

OK so here is the deal. I am going to create a new branch that you can do PR's for the code generator script. I am overly cautious messing around with that script as it is very fragile. I did not write it and it really needs to be trashed and a new one written. It's a large undertaking to do that. I wrote the API generator script that is in LVGL currently and I would much rather use that to generate the code.

Ideally I want to flatten the current MicroPython API so it is as close to identical as possible to the LVGL C API. This would make things a whole lot easier for the user because they would be able to use the LVGL documentation to find things but also porting code over to python would be a breeze to do.

In all honesty I feel that using the code generator script is a real annoyance because it is fragile and fixing it when it breaks can be a headache. I think that hard coding the Binding would be the way to go. it is easy to locate problems and fix them when it is hard coded. There are some portions of it that can be automatically generated, like the get and set style functions for example.