In Edje and Elementary, we have part objects, which are what is returned
by the interface efl_part(). Those objects can't be of an opaque type as
this doesn't work nicely with strongly typed languages such as C++ or
C#. In JS, Lua, C the types are weak and mostly runtime-based so it
doesn't matter much.
As a consequence, the documentation and the types need to look nice in
this EO API. Thus, we remove the abusive term "internal" and explicitly
call all those classes "part" something.
Eventually we want the types to be declared in the EO file so bindings
(C#, C++, ...) can generate the proper access methods, returning the
best possible types.
Note that right now a few of those part types are used in the legacy API
but don't actually need to be exposed externally.
This is kind of a mega commit that does all the renaming at once, but
it's really just a big sed operation. The power of good IDEs :)
Ref T5315
Ref T5306
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
It was always returning true. There is little point in returning
a bool here, an invalid scale value (eg. <= 0) wouuld lead to a
state where scale_get() != scale_set() and that's about it.
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.
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
As Dave pointed out, those are meant for internal use by Edje and
the plugins implementation, rather than for apps. This removes
ugly and complex code. Makes me happy :)
Note that I've kept the composition for now. We can remove it
as efl_content_get() must work on the part handle anyway. But it
can be used as a quick solution.
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 implements edje_object_part_external_object_get() using
efl_content_get() on the part object. Note that there are now
two ways to call APIs on the external part:
- direct call to the efl_part() as if it was the object itself
(implemented by composition),
- get a handle with efl_content_get(efl_part()) and manipulate
it directly (it is the real object).
Do we need this? Do we need the composition trick? Should we have
only one of those solutions implemented?
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)
Jean-Philippe Andre
Amitesh Singh
Daniel Hirt