PVS sudio thought this was odd and it was a bit. not a real issue as a
mem alloc failure herw would still be fatal and simply a crash... as
opposed to a clean "out of mem" and fatal exit then...
error out eally was not finding originally allocated color and the
malloc should have been a mem_alloc() that guarantees a valid memory
return (or termintion of the process).
@fix
Summary:
Some of latest touchscreen devices can report if the tool in contact
is the palm of your hand and there is no axis label for this palm flag.
This adds ECORE_AXIS_LABEL_TOUCH_PALM enum as Ecore_Axis_Label type.
Test Plan: N/A
Reviewers: raster, cedric, jpeg, jypark, devilhorns, ManMower
Reviewed By: jpeg
Subscribers: JHyun
Differential Revision: https://phab.enlightenment.org/D4848
All windows should be standard, really. Except when using legacy
elm_win_add() or if type_set() was called with a specific type.
I dislike type_set...
Ref T5322
This was broken since over a year. Happened during the automatic eo4
migration in f21ade6123.
Thanks goes to the gcc warning misleading-indentation:
evas-3d-shadows.c:163:4: warning: this ‘else’ clause does not guard... [-Wmisleading-indentation]
else
^~~~
evas-3d-shadows.c:165:6: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘else’
evas_canvas3d_node_look_at_set(scene->mediator, EVAS_CANVAS3D_SPACE_PARENT, 0.0, 3.0, 0.0, EVAS_CANVAS3D_SPACE_PARENT, 0.0, 5.0, 0.0);
This removes Evas.Modifier_Mask from EO.
This introduces two new types instead:
- Efl.Input.Modifier
- Efl.Input.Lock
Those are enums, not strings, containing all the known and
currently supported lock and modifier keys. The enums are
bit masks.
This effectively removes the ability for an application to
create and handle specific modifier or lock keys - with EO
API (legacy compatibility is unchanged, of course). I wonder
who ever required this?
Such an ugly API. This is an API to match a string to a number,
build a bitmask from it, and then use that. The supported
strings are well known (should be enum) and would need a
recompilation (ABI update) to support anything new anyway.
Fixes a race that's either really hard to hit if you're a developer
or really easy to hit if you're a user.
Thanks to ApB for the debug assistance.
Fix T5484
Summary:
These routines all already have a @return line that states the return
values appropriately; it's unnecessary to restate the return values in
the documentation text.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4878
This may be a bit more controversial...
But Evas_Coord really is just an int and all the internals
of EFL assume that the base coordinate type is a 32-bit int.
So this type is a bit redondant and can't easily be changed
to, say, a float or int64.
Ref T5312
We only need it in elm_config.
This removes the type Evas_Font_Hinting_Flags from EO,
as well as the functions font_hinting_set/get and
font_hinting_can_hint.
Ref T5312
Note: it seems the EAPI evas_touch_point_list_xy_get() was
lst at some point, as it doesn't appear in the headers anymore.
It looks like we fail to catch an ABI break! abi_checker didn't
catch this!?
Ref T5312
This makes photocam implement Efl.Flipable and Efl.Orientation
in order to use the proper API.
image_orient is now split into two function calls.
Ref T5312
In trying to clean up some code and fix a hypothetical buffer leak, I added
a use after free error that can break rendering on the drm and gl_drm
evas engines.
Coverity did the heavy lifting for me on this one.
Fix Coverity CID 1375047
Fix T5484
Removes the previous "busy" flag, as now we might have an fb attached to
multiple outputs at once, and need to be careful to destroy them only
after they've been removed from all outputs.
Removed the old "busy_set" API which nothing used, and renames fb_destroy
to fb_discard to make it more clear that it's not immediately destroyed.
It's all beta api, so I can do this.