LVGL can delete objects directly with obj.delete, or indirectly by having a parent deleted or cleaned (screen.clean() for example). But the Python object which acts as an interface to the LVGL object remains an apparently valid instance, but further calls to it (label.set_text, for example) crashes my ESP32.
So, simple question: how can you securely delete both an LVGL object and the Python “wrapper” object which serves as its MP interface, even when the underlying object gets deleted on the LVGL side, e.g. as a child of a deleted parent?
The Micropython-LVGL binding is a thin wrapper around LVGL C functions that exposes the LVGL C API in Micropython. In that sense, the Micropython API shares many things in common with C.
In C, if you have a pointer to an LVGL object and delete that object, the pointer would still point to that invalid object and will crash your system if you try to access it. LVGL Micropython objects in fact wrap pointers and behave the same way.
I agree that it could be nicer if the Micropython Binding handled object deletion in a more elegant way, but that would have a cost.
To support this feature we would need to automatically invalidate a Micropython object whenever the corresponding LVGL object is deleted, therefore the Binding would need to:
Register an event handler for each LVGL object and listen for the LV_EVENT_DELETE event
Maintain a state per object whether the object is valid
Check the object validity on every member function of an LVGL Micropython object
and the costs are:
More RAM spent for every LVGL object (to keep the validity state and registered event)
More cycles spent when creating an object and when accessing member functions
Development effort for this feature
So the question comes to that - how important is this feature? Does it worth the cost? What is the impact of not implementing it and requiring the user to avoid accessing invalid objects?