Summary:
adapter can be null if it was previously destroyed
@fix
Depends on D9001
Reviewers: bu5hm4n
Reviewed By: bu5hm4n
Subscribers: bu5hm4n, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D9002
update order can be quite expensive, so this here tries to skip it as
often as possible.
ref T7384
Reviewed-by: SangHyeon Jade Lee <sh10233.lee@samsung.com>
Differential Revision: https://phab.enlightenment.org/D8367
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8209
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8171
this takes the current generated output from eolian for legacy code in
efl and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8169
these API names have been considered a better choice.
ref T7571
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D7994
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.
Mike Blumenkrantz
Marcel Hollerbach
Marcel Hollerbach