| | | | |abstract Efl.Object | | | | |├ (P) parent | | | | |├ (P) name | | | | |├ (P) comment | | | | |├ (P) event_global_freeze_count | | | | |├ (P) event_freeze_count | | | | |├ (P) finalized | | | | |├ (P) invalidated | | | | |├ (P) invalidating | | | | |├ (P) allow_parent_unref | | | | |├ (M) debug_name_override | | | | |├ (M) provider_find | | | | |├ (M) constructor | | | | |├ (M) destructor | | | | |├ (M) finalize | | | | |├ (M) invalidate | | | | |├ (M) noref | | | | |├ (M) name_find | | | | |├ (M) event_thaw | | | | |├ (M) event_freeze | | | | |├ (M) event_global_thaw | | | | |├ (M) event_global_freeze | | | | |├ (M) event_callback_stop | | | | |├ (M) event_callback_forwarder_priority_add | | | | |├ (M) event_callback_forwarder_del | | | | |├ (M) children_iterator_new | | | | |├ (M) composite_attach | | | | |├ (M) composite_detach | | | | |├ (M) composite_part_is | | | | |├ (E) del | | | | |├ (E) invalidate | | | | |├ (E) noref | | | | |├ (E) destruct
Description
Details
Status | Assigned | Task | ||
---|---|---|---|---|
Resolved | zmike | T7512 efl.ui.layout | ||
Resolved | zmike | T7511 efl.ui.win | ||
Duplicate | singh.amitesh | T5363 Cleanup elm_widget.eo | ||
Resolved | zmike | T7553 efl.ui.widget | ||
Resolved | zmike | T7554 efl.canvas.group | ||
Resolved | zmike | T7555 efl.canvas.object | ||
Resolved | None | T7556 efl.loop_consumer | ||
Resolved | bu5hm4n | T7688 Roadmap to stable eo | ||
Resolved | cedric | T7557 efl.object |
We probebly should document this here with a few nice Sequence diagrams, as its not quite obvious when which calls are happening ...
If you mean the lifecycle calls, I agree completely. I'd love to understand what do (P) finalized, (P) invalidated, (P) invalidating, (M) finalize, (M) invalidate, (M) noref, (E) del, (E) invalidate, (E) noref and (E) destruct mean.
Other than that, i would say that everything except composite APIs and allow_parent_unref can be stable. Thoughts ?
This output needs to be updated but the lua script I was using doesn't work anymore.
In short, the lifecycle works something like this:
- constructor - callback for instantiating the class
- finalize - callback for after the constructors are called but before the created object is returned
- invalidate - occurs when an object's parent has been unset (parent_set(NULL))
- noref - occurs when the object's refcount reaches 0
- del - occurs when the object starts to be deleted
- destruct - occurs when the object is destroyed
There are some functions for determining exactly where in the deletion chain an object is:
- invalidated - the object's parent has been unset
- invalidating - the object's parent is being unset (i.e., during the parent_set(NULL) call)
@lauromoura Afaics this only affects bindings, but not the efl.object definition perse. @segfaultxavi improved the documentation big time. To me the API looks good, except one tiny thing, i don't know if we want to have allow_parent_unref out of beta or not, because to me this seems like a hack that should not be needed in future, opinions @zmike @cedric.
I didn't explicitely close the task and phab decided to do it on its own. If we are all fine with efl_object, then let's close this one.