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
When I first implemented the Efl.Container interface I made a mistake of
mixing "single slot" content API's with "multiple children" content
API's. This should fix that, by separating API's that are for a single
part and those that deal with a list of children.
Efl.Content: Single slot. This will be used a lot by efl_part()
objects, and for the default content of widgets (eg. the window
content).
Efl.Container: Multiple children. Used by lists, boxes, layouts
(edje/elm), etc...
I didn't see any class that implemented both interfaces (note: Layout
implements Container and Button implements Content, so technically
Button implements both through inheritance).
For now the eo_prefix is not changed in Efl.Container. I wonder if it
should be reset (to efl_container) or not. This would only affect the C
API.
Ref T5328
This reverts commit ef3d2120bf.
This breaks E. pager ono my right screen looks like:
http://devs.enlightenment.org/~raster/shot-2017-11-11_12-13-14.png
on my left screen shellf keeps swapping between 2 dizes wobbling back
and forth every frame eating cpu and making it "blurry"...
note - theme is the flat one in devs/raster/theme/flat2 branch. so
this change certainly breaks something...
As most of you know, TEXT part was, up to this point, an Evas.Text
object.
This patch merges TEXT and TEXTBLOCK both to use Efl.Canvas.Text.
Code is added to emulate what TEXT did that TEXTBLOCK did not.
I believe we can move forward with TEXT, and deperacate TEXTBLOCK from
the EDC. You can also set markup to TEXT parts.
Exactness seems to show some differences, but further examination shows
that it's due to difference in how width is calculated in
Efl.Canvas.Text. The results seem correct.
Be sure to report of any breakage via Phabricator or contact me
directly.
I am running E with this and did not stumble upon any crashes or visual
bugs.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Call provider_find on the loop (or basically any object) with the
color/text/size class interface instead, to find it. The main loop is
the main holder of those objects.
Note: This makes use of provider_find instead of direct access to the
variable, in order to self-test the code. In theory release builds will
not do this and user directly the variable.
Summary:
It should return width and height with positive values or zero.
@fix
Test Plan: make check
Reviewers: raster, jpeg, cedric
Reviewed By: raster
Subscribers: jiin.moon
Differential Revision: https://phab.enlightenment.org/D5422
Keep the legacy code path when using edje_object_part_text_set.
Fixes e's notification that got broken after
3642b3ae67.
Also, limit new efl_text_markup set to TEXTBLOCK parts.
Users can now do either:
efl_text_set(efl_part(obj, "part"), "text");
efl_text_markup_set(efl_part(obj, "part"), "text");
Also have efl_text_get/markup_get.
Using markup_set will allow to choose whether to set a markup or a text
to the text part.
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.
For this patch I decided to add a pseudo legacy wrapper as the function
is called in a very large number of places. Fixing all those calls to
use the size2d form is a lot of work and a greater risk of b0rking
something.
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
Summary:
When user drags slider, slider value cannot be changed by API.
However the necessity of above behavior has emerged.
Because sometimes applications want limitation of slider value.
Test Plan: elementary_test -> slider -> Limited
Reviewers: woohyun, cedric, SanghyeonLee, singh.amitesh, jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4883
Summary:
From EFL 1.19, Edje Textblock calculation logic was fixed according to
Edje documents. But, it broke old edje files which ignored text.min
option for minimum width. Even if the old edje files were wrong,
we need to support them as discussed from T5548.
Also, this patch will change default efl_version to 1.18 from 1.19.
So, without efl_version property, edje file will run on the legacy logic.
Fixes T5548
Test Plan: Turn on/off presentation mode in Enlightenment.
Reviewers: herdsman, cedric, jpeg, zmike, raster
Subscribers: stefan_schmidt
Maniphest Tasks: T5548
Differential Revision: https://phab.enlightenment.org/D4967
Adjusted by @jpeg
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.
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
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...
prev_description was used when HAVE_EPHYSICS is set, which is the
default, but I also added a use in 7072fbc2bf where the map
was not properly reset.
This removes an ugly #ifdef and opens the door to other fixes
similar to that map one.
In the following sequence, the swallowed object map property is
never reset as it should have been:
- swallow object
- start program, change state to have a map
- do something
- start program, change state to have no map
but before render, unswallow the object
At this point, the object will never be un-mapped. This is weird.
Somehow edje_calc avoids calling evas_object_map_[enable_]_set
excessively, but I believe the issue is that the object does not
need recalc. Its container needed recalc, not the child (which is
mapped). I'm not 100% sure.
Test case:
elementary_test -to "Genlist Decorate Item Mode"
Click on rotate, select a few items, scroll up and down. Enjoy.
Ref T1551
@fix
Jean-Philippe Andre
Cedric BAIL
Carsten Haitzler
Daniel Hirt
Jee-Yong Um
Youngbok Shin
Hosang Kim
Jihoon Kim
Mike Blumenkrantz
