Summary:
The patch was created for EFL 1.18. But, it was merged for EFL 1.20.
@fix
Test Plan: N/A
Reviewers: herdsman, jpeg, cedric
Differential Revision: https://phab.enlightenment.org/D4968
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
There are many requests to add a new feature for handling horizontal align
according to current locale. For example, in RTL locale setting,
users want to see right aligned text for every list's item.
Even if some of list's items only contain LTR characters!
It is useful for the needs.
@feature
Test Plan: N/A
Reviewers: herdsman, tasn, woohyun, raster, cedric
Reviewed By: herdsman, raster
Subscribers: z-wony, jpeg
Differential Revision: https://phab.enlightenment.org/D4664
After finalize, the type of an input device can not be changed.
So, deprecate the function and prevent anything from happening
unless we're inside efl_add().
Ref T5515
1. The word "class" is a pain point with many languages where
it's a keyword. Type is a little better. Also, the property
was already named "device_type" and not "device_class".
2. Remove Efl.Input.Device.Sub_Class
It's not used inside EFL upstream codebase, and unlikely to
be used anywhere else (even in Tizen).
Hopefully no one used the Efl_ enum types. So far only the Evas_
types should be in used.
Ref T5540
Summary:
Wordsmith phrasings to be a bit more concise. In example code,
distinguish better between the OOM and Low Mem conditions that it
is demonstrating.
Reviewers: cedric
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D4898
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This size hint is only used by naviframe, which is not part of
our EO widgets. I also believe it might be an even more confusing
hint than the others.
I kept the typedef as is in Evas_Legacy.h in case an app is
written using EFL_GFX_ instead of EVAS_...
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
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
Summary:
Straightens up grammar and simplifies phrasing to make the functions
purposes clearer.
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4874
This patch introduces possibility to enable key locks and modifers by seat.
It's very useful when the user has two keyboards attached to different seats.
Summary:
It should be evas_device_add_full() in order to follow the EFL
name pattern.
Reviewers: DaveMDS, bdilly
Reviewed By: DaveMDS, bdilly
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4325
This removes:
Efl.Event interface
And renames:
Efl.Event.Input -> Efl.Input.Event
Efl.Event -> Efl.Input.Event (merged)
Efl.Event.Pointer -> Efl.Input.Pointer
Efl.Event.Key -> Efl.Input.Key
Efl.Event.Hold -> Efl.Input.Hold
This also moves some interfaces from efl/ to evas/ where they
belong better.
This allows renaming Eo_Event to Efl_Event.
This is for Wacom graphics tablets (with a pen).
The raw data sent by ecore to evas (and then to apps) is pretty
useless as it's not normalized, and apps have no way of knowing the
dimensions of the tablet, without themselves opening the device
(we don't know nor expose the path to the device).
This is for Xi2 only for now, as Wayland support hasn't been done
yet.
The intent is to deprecate LABEL_X and LABEL_Y. I'm not sure yet
if the normalized value is useful or not (it would seem we may not
be able to provide this info in Wayland).
The new WINDOW_X, WINDOW_Y labels will be used in the new event
type (Efl.Event.Pointer). Normalized values are not exposed yet,
let's decide if we want them or not first (based on what can be
done in Wayland space).
@feature
smart_get and attach referred to an opaque struct, from EO
point of view.
Also, attach was an EO-only function, used nowhere besides
evas object smart itself, and evas grid (which is not EO
public API).