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
Summary:
In singleline textblock, using "text.min: 1 0" and min, max width,
Edje allows to use expandable text with ellipsis. It shows ellipsis
when only text's width reach the max width.
But, Edje couldn't support same feature on multiline textblock.
Edje dose not use max height or text.max properly if ellipsis is enabled.
This feature is very useful to make a layout with dynamically aligned text.
@fix
Reviewers: cedric, tasn, woohyun, raster, herdsman
Subscribers: z-wony, eagleeye, jpeg
Differential Revision: https://phab.enlightenment.org/D3595
Summary:
_edje_part_***_set/get (for mouse_events, repeat_events, ignore_flags, mask_flags)
overwrite cached edje value. These behaviors affect all edje object added after
these changes, and result in not intended.
@fix
Reviewers: jpeg, cedric
Subscribers: akanad, woohyun
Differential Revision: https://phab.enlightenment.org/D4362
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Summary:
There can be the case that the file of a edje is NULL. Even if this case
is a bit strange, we should not crash on it.
Sample code which produces the crash:
Edje_Object *edje;
int r, g, b, a;
edje = edje_object_add(evas);
edje_obj_color_class_get(edje, "bla",
EDJE_COLOR_CLASS_MODE_COLOR, &r, &g, &b, &a);
So better protect against this case.
Reviewers: raster, herdsman
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4277
- 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
edje was keeping every edje object created in an eina list so it could
access them later. not really great when every list node contains at
least 4 pointers (data, next, prev and accounting, possibly magic
too). also ever time an edje object is deleted it has to remove from
this list which means... walking the list to where the obj is... not
great. replace with an inlist which is just 3 ptrs, no extra pressure
on list pool and removal os O(1) too.
@optimize
What a mess... Assuming efl_part() had no side effect on the
object it took me hours to figure out that there was a wrong
call to _edje_recalc_do in the efl_part() function itself.
That was bad, and existed because efl_part() used to be
efl_content_get().
efl_part() should not have any side effect.
Also, fix a return value in content_remove.
Fixes T4214 (invalid redraw and crash in terminology).
Summary: Need discussion about the repeat_events property
Test Plan: Swallow an object which has EINA_TRUE repeat_events to a swallow part which has EINA_FALSE repeat_events
Reviewers: Hermet, cedric, raster, jpeg
Reviewed By: raster, jpeg
Subscribers: jaehwan, seoz, woohyun
Differential Revision: https://phab.enlightenment.org/D3580
Summary:
If color class of an edje part is defined as "aaa/bbb/ccc/ddd",
edje will search for color class by the following sequence.
"aaa/bbb/ccc/ddd"
"aaa/bbb/ddd"
"aaa/ddd"
"ddd"
So, without additional lookup table, edje classes (color, text, size)
can have the functionality like inheritance.
Reviewers: jpeg, raster, cedric
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4127
Signed-off-by: Cedric Bail <cedric@osg.samsung.com>
Daniel Hirt
Jean-Philippe Andre
Hosang Kim
Youngbok Shin
Jihoon Kim
Mike Blumenkrantz
Jee-Yong Um
Cedric BAIL
Jee-Yong Um
Marcel Hollerbach
Tom Hacohen
Carsten Haitzler
Davide Andreoli
Shinwoo Kim