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
This commit add the event "circular,dependency" for edje object. Given
event is called when edje found the circular dependency between parts
in object. This event will be usefull and informative paired with
Edje_Edit API.
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
calc_size_min was just a helper passing 0,0 to the restricted form.
Let's not duplicate APIs in EO and use an optional argument instead.
Bindings should be nicer and C could use a macro if it's too cumbersome
to pass in 0,0.
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 is really only a demonstration of what kind of information
we can print with efl_debug_name_get(). Hopefully this can help
debugging with printf/ERR logs and even help with live debugging
inside gdb.
This shouldn't be used for other purposes than debugging, as the
exact string format is not defined.
@feature
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 changes a few method names:
- freeze -> calc_freeze
- thaw -> calc_thaw
- update_hints -> calc_update_hints
Otherwise this is mostly about reshuffling the EO file itself
and changing documentation.
Ref T5315
Still not happy with the name. I'm trying to avoid a name
clash between other "data" elements in the object. This is
the EDC group "data item".
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?
Since this uses generic_value (aka Eina_Value), there is an
implicit type detection and conversion. I did not attempt to
cover all types (namely string+int and string+float and even
less sets of those) as I believe they aren't really used. Or
they most likely could be replaced by multiple messages rather
than a single message.
Note: should we pass ptr(generic_value) instead of generic_value?
The API looks a little odd in C when passing by value.
@feature
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.
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
Summary: I had fixed some typos and wrong expressions, euch as capital letters, singular Etc. in Ecore and Edje API reference doxygen.
Test Plan: Doxygen Revision
Reviewers: stefan, cedric, raster, Jaehyun_Cho, jpeg
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4677
Amitesh Singh
Jean-Philippe Andre
Vyacheslav Reutskiy
Jee-Yong Um
Daniel Kolesa
Cedric Bail
Daniel Hirt
Jihoon Kim
Myoungwoon Roy, Kim