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>
The following situation:
- A Box in a naviframe, with n children.
- All added children register to the focus graph with the box as parent,
order gets set correctly.
- Naviframe hides this item, so box property tree unfocusable gets set
to true, it gets unregistered from the focus graph, even every single
child gets unregistered.
- The item gets shown - every child and the table are getting
registered again.
- Order is not set again, since the box does not get changed
- Order of the children is mixed up.
This should fix this case since the order is flushed every time the box
gets registered.
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.
It's unlikely that we'll have other stuff under Ip namespace, also not
that likely to have other than Ip Addresses (to invert it to
Address.Ip), thus make a toplevel entry Ip_Address as suggested by
DaveMDS.
Test case:
elementary_test -to "Gesture Layer"
Just move the pictures around (eg. to the bottom). They could
disappear entirely.
This is because the geometry used was based on the smart
object "bounding box" rather than the mapped output.
@fix
This is the first step toward handling multi output. This patch
remove engine.data.output from Evas structure and use an Eina_List
for it instead. It also start moving code around to fetch an output
or an engine context (which are the same at the moment, but will be
split in a later patch).
Summary:
Fixes some grammar confusion for in that/this, that/which, to/at,
to/for, at/by, etc.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4806
Summary:
Rounding the sum of glyph's advance could cause inconsistency of
each glyph's positions. When Evas enables Harfbuzz library,
Each glyph's position has to be handled by only nearby glyphs.
But, currently, totally unrelated glyph's advacne could change
other glyphs positions.
ex) 1. "connect."
2. "Tap here to connect."
You can see different gap between "c" and "o" of word "connect".
It should be same even if there was a different text before the word "connect".
@fix
Test Plan: N/A
Reviewers: raster, herdsman, jpeg
Reviewed By: raster
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4782
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.
Putting the PAGE_FLIP_EVENT flag on the set rotation request resulted
in an extra event on the drm device fd that screwed up page flipping
badly from that point on.
@fix
since this code's creation it seems that the internal int size was set to use
short in order to micro-optimize memory usage, while the api function parameters
used Eina_Rectangle which had a larger int size. when initializing the internal
rect struct, this would lead to overflows which resulted in broken tilers which
returned iterators with no valid rects after having valid rects added
test case: run weston-subsurfaces
@fix
the api function requires this, but the unified handler for api+edje handler does
not, since edje singals are deferred and the button which triggered the move
may be released before the signal is processed
ref ea7bbfe47d
@fix
We don't need to keep this in eo files anymore because the APIs
using them are now fully in C. This also allows removal of the
event callback builtin from Eolian.