Actually I’m using mostly compiled .mpy for my projects.this PR which was not accepted in upstream yet, but I’ve integrated it into lv_micropython.
I can’t find it there. Did you push it to GitHub?
We have discussions over Micropython for v8 on:
opened 10:15AM - 31 Aug 20 UTC
closed 08:53PM - 28 May 22 UTC
pinned
For Micropython (or other future) binding to work correctly, **certain API namin… g conventions must be followed**.
LVGL API in general follows these conventions. However, in certain cases these conventions were missed.
Examples for such problems:
- #1750
- [lv_list_get_* issues](https://forum.lvgl.io/t/help-lv-list-maybe-have-bugs/3111) and [this post](https://forum.lvgl.io/t/event-handler-for-list/3529)
- `lv_page_glue_obj`
- `lv_win_close_event_cb` receives `btn` instead of `win`
- Return value is `lv_obj_t` instead of a more specific object, in [`lv_tabview_add_tab` for example](https://forum.lvgl.io/t/working-with-pages-of-a-tabview/3730).
- Ambiguity: `lv_anim_start` collides with `start` member of `lv_anim_t`. [Both map to `anim.start`](https://github.com/lvgl/lv_examples/issues/83#issuecomment-727273239-permalink:~:text=The%20reason%20we%20call%20lv.anim_t.start(a)%20and,which%20shadows%20the%20member%20function%20lv_anim_start.).
Changing the API breaks it, so we cannot fix that for v7 (although there are workarounds)
Therefore - **I suggest reviewing LVGL API before releasing v8**, and checking that the following conventions are followed:
- [ ] A function that returns a pointer to a specific widget should return a pointer to that widget and not to a generic `lv_obj_t`.
For example, `lv_tabview_add_tab` should return `lv_page_t` instead of `lv_obj_t`.
- [x] Widget member function must start with lv_\<widgetName\>
- [x] Widget member function must receive `lv_obj_t *` as its first argument, and this argument must be a pointer to the Widget objects itself.
For example, `lv_page_glue_obj` should receive the page object as the first argument, and not the object that should be glued.
- [ ] Widget constructor must be named `lv_<widgetName>_create` and receive `lv_obj_t * par` as its first argument. It can have additional arguments. For example: `lv_obj_t * lv_btn_create(lv_obj_t * par, const lv_obj_t * copy);`
- [ ] lv_set_event_cb must be reimplemented and not inherited from lv_obj, if we want the callback to receive the component and not lv_obj as argument. See [this post](https://forum.lvgl.io/t/event-handler-for-list/3529). (Can be implemented as static inline wrapper so no C overhead)
- [ ] Need to verify these conventions for both core and external widgets, such as [lv_lib_qrcode](https://github.com/lvgl/lv_lib_qrcode)
- [x] Member functions of structs should follow the Widget conventions.
They should receive a pointer to the struct as the first argument, and the prefix of the struct name should be used as the prefix of the function name (for example **lv_indev_drv**_register(**lv_indev_drv**_t * driver) )
- [ ] Avoid ambiguity in between struct members and struct member functions. (For example `start` in `lv_anim_t`)
- [x] [Callback conventions](https://github.com/lvgl/lv_binding_micropython#callbacks) must be followed:
- There's a struct that contains a field called `void * user_data`.
- A pointer to that struct is provided as the first argument of a callback registration function.
- A pointer to that struct is provided as the first argument of the callback itself.
OR
- A parameter called `void * user_data` is provided to the registration function as the last argument.
- The callback itself recieves `void * user_data` as the last argument
- [x] Callbacks that are not available for the Binding must include the string `xcb`
- [x] All global pointers to dynamically allocated RAM must be defined as [GC roots](https://github.com/lvgl/lvgl/blob/d8a37e8fd8552c7ae8cfadde152a548051d6359d/src/lv_misc/lv_gc.h#L28-L45) and accessed with `LV_GC_ROOT` macro.
- [x] Functions which are not part of the public API must begin with underscore, to mark them as "private".
- [ ] Some structs should not be used directly by the user. Instead, LVGL provides many setter/getter functions. For example `lv_anim_t` has `lv_anim_set_path` to set the path instead of directly writing to `path` field of `lv_anim_t`.
In order to minimize the API size, it's better to mark such structs as "private" by prefixing them by underscore. This way the binding script would know not to wrap every field in them, and treat them as opaque objects instead.
- [x] Strings must be passed as `const char *`
- [x] Arrays must be passed with square brackets and **not** as pointers. For example: `lv_draw_triangle(const lv_point_t points[]`
- [x] Argument must be named also on H files (For example `void lv_style_list_remove_style(lv_style_list_t * list, ...` but not `void lv_style_list_remove_style(lv_style_list_t *, ...`)
- [x] Constants should be declared as enums instead of macros, when possible. (enums are visible to the bindings, macros are not)
- [x] C Macros are not available in the binding. Add static inline functions to encapsulate macros for macros that should be part of the API. ([For example, `lv_color_hex`](https://github.com/lvgl/lvgl/blob/652809d0059e57320c2b58102c47dbde3622d6b0/lv_misc/lv_color.h#L405-L411))
- [x] All function prototypes must have implementation
- [x] Function prototypes must not be duplicated
---
### Update
- [ ] Function arguments that are pointers to `struct_type` should be declared in the function prototype as `struct_type *` and not `void *`.
For example, callbacks on `lv_fs.h` should receive `lv_fs_file_t * file_p` and not `void * file_p`.
- [ ] Widget name must not be a prefix of another widget name. For example, we can't have both `dropdown` and `dropdown_list` widgets.
There are still a few questions open, but I think we are ready to start trying the bindings on v8.
Regarding CMake (only relevant to ESP32) I actually started working on that.CMakeLists.txt on lv_micropython_bindings root which will take care of running the bindings script etc. which is nicer than what we have today where Micropython’s makefile contains LVGL bindings rules.
Actually I’m giving it a higher priority because I need esp-idf 4.2 working with lv_micropython so I’m working on that first and then plan to move on to v8.
We would definitely be glad to get you help there! Thanks!