Summary: I had fixed some typos and some wrong expressions in API reference doc
Test Plan: N/A
Reviewers: raster, zmike, Hermet, segfaultxavi
Reviewed By: Hermet
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6943
elm_entry_prediction_hint_hash_set API sets the prediction hint data at the specified key, and
elm_entry_prediction_hint_hash_del API is for deleting the prediction hint data identified by a key.
@feature
Signed-off-by: Jihoon Kim <jihoon48.kim@samsung.com>
Note: Edje.Perspective is not bound to EO, and this is the only reason
why I'm moving this to legacy only. Marking as beta would mean the
legacy APIs would not be generated, so that would have almost the same
effect as moving to legacy.
It would be nice to actually support this in EO, though this seems like
a rarely used feature.
Ref T5315
This should probably be replaced by a well defined signal.
Note: If edje sends signals on swallow/unswallow and text set/unset we
could simplify some of the elementary code, eg. for button's icon
handling. The theme should be handling the padding automatically, it's
not the elementary widget's role
Ref T5315
EO file API is still in flux, especially wrt. async loading. Let's just
keep this in legacy for now.
A few more patches and Edje.Object will reach its final form.
Ref T5315
For now I made this EO-only but this definitely could be expose in
legacy API as well.
This simply gives exact information about the type of part, after doing
a recursive search. Edit Edit doesn't do a recursive search, only a
direct one, which can yield invalid results (eg. RECT or NONE instead of
TEXT in case of "elm.units.max" for a slider).
@feature
Those APIs can then be used by Elm.Layout, hopefully
simplifying the API.
I wonder if the APIs should be prefixed "calc_" (as is)
or "layout_calc_". The extra "layout_" prefix would make
it common with other layout APIs (eg. signals, data,
size min/max, ...).
Ref T5315
This API is used by elementary widgets like:
edje_object_base_scale_get(elm_layout_edje_get(ly));
This means elm_layout in fact should also expose it directly.
Ref T5315
The following API is now supported with efl_part:
- Efl.Text.text { set; get; }
- Efl.Text.Cursor.cursor { get; }
- Efl.Text.Cursor.cursor_paragraph_first;
- Efl.Text.Cursor.cursor_paragraph_last;
- Efl.Text.Cursor.cursor_position { set; get; }
- Efl.Text.Cursor.cursor_coord_set;
- Efl.Text.Cursor.cursor_line_char_first;
- Efl.Text.Cursor.cursor_line_char_last;
- Efl.Text.Cursor.cursor_char_next;
- Efl.Text.Cursor.cursor_char_prev;
- Efl.Text.Cursor.cursor_line_jump_by;
- Efl.Text.Cursor.cursor_copy;
- Efl.Text.Cursor.cursor_content { get; }
- Efl.Text.Cursor.cursor_geometry { get; }
- Efl.Text.Cursor.cursor_text_insert;
Many of the 'part_text' functionality was moved to legacy, too.
See the edje_object.eo to see which ones are still supported.
You now use the following:
efl_text_set(efl_part(edje_obj, "part"), "text");
const char *text = efl_text_get(efl_part(edje_obj, "part"));
The former method of edje_object_part_text_set/get is now legacy.
Also, adjusted 'tests/emotion/emotion_test_main-eo.c' with
this change.
This introduces the new interface Efl.Ui.Base, intended to
share some APIs between Edje and Elm:
- mirrored (rtl)
- language
- scale
base_scale remains in Edje.Object for now. I don't think it
applies to generic widgets.
The new interface uses eo prefix "efl_ui". It could be renamed
as Efl.Ui (no Base), or anything else. As always, I'm open to
propositions!
Ref T5315
This moves all part_drag APIs to legacy and implements them for
EO using efl_part(). All parts now support these APIs, even if
they are not draggable. Making this more fine grained would
probably be much extra work for little gain.
This creates a new interface Efl.Ui.Drag.
This adds a new class: Efl.Canvas.Layout.External.
I hate this long name...
This class represents an external part, and for now only
supports param_set/get as well as param_type_get. For now
param_type_get() still returns an Edje_External_Param_Type and
not another more generic type.
TODO: enumerate choices, return object, return content
Original patch by Jinwoo Shin:
If edje has multiple levels of child group,
edje_object_message_signal_process cannot process message on
child group. To cover that, it needs to add new API which
traverses its hierarchy and process messages.
@feature
Signed-off-by: jinwoo.shin <jw0227.shin@samsung.com>
Differential Revision: https://phab.enlightenment.org/D4914
This refactors even more the edje part eo internals. But now
common part APIs can easily be implemented in edje_part.c
The API now looks like:
efl_gfx_geometry_get(efl_part(edje, "part"), &x, &y, &w, &h)
Ooooh. This one might be controversial, as some apps definitely
use the function. But it is so easily abused. For our EO API
we are trying to not expose any internal object, as this prevents
us from making changes to the internal behaviour and structure.
All the features that this API provided should be limited to
read-only access to the internal object. In order to replace
this, we will have to return an Efl.Part object that implements
all those APIs: geometry_get, visibility_get, etc...
Most of the values were the same, with edje having just a couple
more error codes.
Not entirely sure the prefix Efl.Image is correct for this type.
Maybe just Efl.Load.Error?
It is used to receive messages with a payload from embryo to C.
This API has a function pointer, which means it would have to be
manually bound, or transformed (eg. eo event).
Also, prepare the change for message_send to use Eina_Value and
no explicit type.
This feature seems rarely used.
But note that handler_set is in fact used in terminology, rage and
luncher. So, if the need arises, it will have to be transformed in
a proper EO way.
Summary: I had fixed some typos and some wrong expressions, such as capital letters, singular, and orders of groups in Edje and Eet API reference doxygen.
Test Plan: Doxygen Revision
Reviewers: stefan, cedric, raster, Jaehyun_Cho, jpeg
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4666
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
- convert methods to property setter/getter
- remove "values" block when getter returns read_only value
- fit the type of params of eo funcs to those of legacy APIs
Summary:
refactor setter and getter of edje color class and
move edje_color_class_set/get() into Edje.Object as class functions
Reviewers: cedric, jpeg
Reviewed By: jpeg
Subscribers: kimcinoo
Differential Revision: https://phab.enlightenment.org/D4109
Note by jpeg:
The EO APIs introduced here will be revisited in upcoming patches,
in particular:
1. avoid non-premultiplied colors
2. move to a common color class interface
This is similar to the previous patch for Box,
but for Table.
Those new EO API as well as the legacy ones still need to
be tested (no test case in make check...)
@feature
Xavi Artigas
Hermet Park
Myoungwoon Roy, Kim
Mike Blumenkrantz
Jihoon Kim
Daniel Hirt
Amitesh Singh
Jean-Philippe Andre
Jee-Yong Um
Carsten Haitzler
Shuhrat Dehkanov