There is the case that the deletion of the adapter can cause another
registeration, which then calls another time prepare, which then deletes
the adapter, before the actaul deletion of the first efl_del happened,
which means it will throw an error. To avoid this we track if we are in
process of a unrealization, and if so, do not delete the item there.
Reviewed-by: YeongJong Lee <yj34.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7453
Summary:
there was a case when a block could be realized while a item that is
realized was brought from one block to the this new one. The block now
is simply realized using api instead of just setting the flag, this sets
the correct focus registrations. While fixing this the error of double
regiration of items came up, this is also fixed by unregistration and
reregistration in the correct block.
fix T7247
Reviewers: zmike, SanghyeonLee, YOhoho
Reviewed By: zmike
Subscribers: Hermet, cedric, #committers
Tags: #efl
Maniphest Tasks: T7247
Differential Revision: https://phab.enlightenment.org/D6737
the manager objects are build on the assertion that registered elements
are returning the manager they are registered on if
efl_ui_focus_object_manager_get is called.
We dont delete the adapeter when we are still focused, to set anyway the
correct view to it, we need to set the view to the adapeter as often as
possible
somehow genlist leaks the view sometimes, thus the adapter is not
deleted when the item is deleted. This resulted in strange ghost focus
objects in the window.
better rely on the adapter and wait for realization so the adapter is
wether created or not even created but used with content. This fixes
item content focus, crashes at startup and a freeze in genlist test!
The problem here was that the adapter we have created would be
recognized as our subchild, and thus we delete our own subchild, which
is wrong. This fixes that problem and keeps the adapter alive.
Marcel Hollerbach
Marcel Hollerbach