it turns out to be very handy to have a interface for the moving and
border elements, that is unconnected to the way of how widgets are
registering themself.
This for example enables us to get a simple focus manager that just
redirects the call into a internal 2 dimensional data struct
Some names have not been changed, hopefully making a distinction
between legacy APIs and internal code (elm_layout_blah) and valid EO
usages.
This means many internal functions are still elm_layout_ as their
sole purpose is to support the legacy API.
Ref T5315
Summary:
node_get() can return NULL sometimes. Add a missing check, and add dox
for the function to document the error return.
>>> CID 1374434: Null pointer dereferences (NULL_RETURNS)
>>> Assigning: "node" = null return value from "node_get".
@fix CID1374434
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4824
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
There could be the case that the item gets freed due to some handling in
a event handler of the event EFL_UI_FOCUS_MANAGER_EVENT_FOCUSED.
So the code now sets the node to NULL after the event is called and
saves the fields that are rfom use later.
Lets say there is a box with the following ordered children:
|Button|Box|Button|Box|Button| the two boxes do not have any children
at the time of the setup. The logic of the order_update will only order
the children like that:
|Button|Button|Button| Which is correct by that time, the two boxes dont
have any children.
Now the two boxes are also getting children, the order will not
selfupdate or anything so the logical chain would be:
|Button|Button|Button|Box|Box|. Which is wrong. To solve that the
manager keeps the order that got set last, and reapplies the order again
if something gets added to the parent where the order was set.
This should fix strange next / prev operations in ephoto.
The Efl.Ui.Focus.Manager abstracts the creation of a localization graph
and a logical tree. The localization graph is used to find a object
right left up or down of a given object. The logical tree is used to
iterate throuw the containers which are used to build a ui.
Those managers can be used bound to some layer in the ui, so for
example the window is a layer, the content of a scroller is a layer.
With those layers, we can make sure that movements of a scroller for
example just means that this graph of objects in the scroller needs to
be recalculated, and not the complete ui.
The advantage of having this to layer bound datastructures is that you
can easily debug those graphs, since the complete layer of this
managerobject can be calculated completly.