Summary:
This clarifies a bit the whole Orientation vs. Direction confusion, at the
expense of longer names (Image_Orientation vs. Layout_Orientation).
Also, the interfaces are now adjectives (Orientable) and the enums have long
names (*_Orientation).
Pretty big patch, but no functional changes.
Relates to T7863
Test Plan:
Everything builds and passes tests.
Elementary_tests show same behavior, including the "inverted" widgets, which
are the only parts which received a bit of code changes.
Proof:
https://travis-ci.org/Enlightenment/efl/builds/536277282
Reviewers: zmike, bu5hm4n, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8946
Remove legacy stuff from Efl.Ui.Box.
This expect to improve performance by removing internal function call related
evas_box.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8417
Use restricted_min_set instead of min_set in layout_update.
min_set is set by public API(user side). if it is changed by internal function,
user will get unexpected value later. please check added test case.
Note that this reverts commit e013480e7a. instead,
this patch provides better solution of the issue refered in e013480e7.
Reviewed-by: Xavi Artigas <xavierartigas@yahoo.es>
Differential Revision: https://phab.enlightenment.org/D8214
Summary:
This patch fixes issue that parent hint size min is ignored when it is greater
than children hint size min sum.
Thanks to segfaultxavi for reporting this.
Test Plan:
1. make check
2. 'hello-gui' or 'texteditor' example in examples.git
Reviewers: segfaultxavi, zmike
Reviewed By: segfaultxavi
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8098
Summary:
There are three reasons to refactor layout_update of Efl.Ui.Table.
=== 1. Inconsistency of hint behavior. ===
Some hint property is often not respected. for example, hint_min is ignored in
Table when it is used with hint_max even if hint_weight is 0. hint_aspect is
always ignored in Table.
The ambiguous behavior make it hard to layout widgets in container. of course,
we documented 'it's just a hint that should be used whenever appropriate.' but i
don't think it means that 'hint API is sometimes respected and we also don't
know when that API is respected.'. at least there is rule for consistent
behavior and we should be able to explain why a widget is located here and
why some hint property is ignored.
So, i'll suggest priority of hint property. this refactoring support following
priority.
1) HintMin
2) HintMin + HintAspect
3) HintMargin
4) HintMax
5) HintAspect
6) HintWeight, HintFill
7) HintAlign
ref T5487
Please check with unit test D7840
=== 2. To Enhance usability. ===
Efl.Ui.Table is using homogeneous mode of evas_table which have same columns,
rows size. but i think a table can generally change columns, rows size and
we can provide homogeneous mode option.(D7892)
In this patch
- table columns(rows) min size is decided by maximum size among its cells
width(height) min size.
- table columns(rows) weight is decided by maximum weight among its cells
horizontal(vertical) weight.
Also, pack_align is implemented. it is used if no item has a weight.
=== 3. To remove internal evas_table. ===
This is low priority work. however, i guess is is necessary for lightweight
container widget. there are two size_hint callback to adjust table size and
efl_canvas_group_calculate is called twice when it is resized.
This patch is first step to remove internal evas_table.
Test Plan:
make check
elementary_test -to 'efl.ui.table'
Reviewers: jpeg, Jaehyun_Cho, zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T5487
Differential Revision: https://phab.enlightenment.org/D7841
Summary:
these hints are not strictly size-related, so renaming them is more consistent
with their actual function
ref T7563
Depends on D7968
Reviewers: segfaultxavi, cedric, bu5hm4n
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7563
Differential Revision: https://phab.enlightenment.org/D7977
Summary:
On homogeneous mode, children are of the same weight and of the same min size
which is determined by maximum min size of children.
Depends on D7750
Reviewers: Jaehyun_Cho, zmike, jpeg
Reviewed By: zmike
Subscribers: segfaultxavi, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7889
Summary:
Current layout_update doesn't consider max hint priority. for example, if it
has hint_max, the size is hint_max value regardless of weight or fill.
moreover, if it has hint_aspect with hint_max, hint_min can be ignored.
(test that aspect(1,3) max(50,150), min(70, 70) then, size has (50, 150))
It seems that hint_max is considered as high priority. however, if hint_min
greater than hint_max, hint_max is ignored.
In order to resolve the hint priority conflict, this refactoring supports
following hint priority.
1) HintMin
2) HintMin + HintAspect
3) HintMargin
4) HintMax
5) HintAspect
6) HintWeight, HintFill
7) HintAlign
ref T5487
Specific unit test is D7463
Test Plan:
make check
elementary_test -to 'efl.ui.box'
Reviewers: jpeg, Jaehyun_Cho, zmike
Reviewed By: zmike
Subscribers: segfaultxavi, zmike, cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T5487
Differential Revision: https://phab.enlightenment.org/D7750
Summary:
If widget use both hint_align(HINT_FILL) and hint_max together, there is no way
to set to hint_align. See, elementary_test -to 'efl.ui.box' -
"Button with a quite long text." button. you can control button position
using "Box align" slider, but this is not proper implementation. When there are
two widget which have hint_align(HINT_FILL) and hint_max, those positions are
determined by box_align rather than hint_align. it means widget align cannot be
set individually.
To solve this problem, this patch add hint_fill property. in order to avoid
conflict with legacy API named evas_object_size_hint_fill_set(), it only works
for EO widgets(made by efl_add).
Also, EFL_GFX_SIZE_HINT_FILL is removed.
@feature
Test Plan:
elementary_test -to 'efl.ui.box'
elementary_test -to 'efl.ui.table'
Reviewers: jpeg, Hermet, Jaehyun_Cho, raster, barbieri
Reviewed By: Jaehyun_Cho
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T3912
Differential Revision: https://phab.enlightenment.org/D7409
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.
Issue: If the item has weight and non-filled align, item is not resized.
This patch fixes this issue.
Test: elementary_test -> ui.box -> Equal weight. Buttons Btn1, BtnA, B, C
do not resize when resize the window.
ref T5487
This led to a completely invalid layout when using the Ui.Box
widget. Clearly the patch hasn't been thought through and tested
properly.
No comment.
Fixes dc022d602d
This reuses the Evas.Box code, since we are still using the
box internally. The flow layout function is far from perfect
(it works well only with items of same height).
This shows how to use specific layouts provided by EFL.
So, since we don't have function pointers, all the solutions
to reimplementing the layout function are quite convoluted:
1. use events
2. reimplement layout func
3. use an extra object
4. use a generic class (non instanciated)
Promises don't apply here (layout will run multiple times).
Problems:
1. Multiple event callbacks will be called, resulting in
potential performance impact, extra events, etc...
Also, there is no way to define standard implementations
that would be provided by the framework.
2. Reimplementation of a function requires extra EO work
(create an EO class, etc...), doesn't allow on-the-fly
change of the layout method.
3. Probably the best solution is to have an object implementing
the layout. But this means creating an extra object along
with the container.
4. To avoid the extra object, use a class, and reimplement
a @class function. This unfortunately requires extra
EO work.
Solution 4. has been selected, but it's not very nice...
This should be the only linear packing container.
This replaces: evas box and elm box.
Edje box needs to be kept around for compatibility,
but it stays an EDC object only (for apps).
Lots of things are still to be fleshed out in this
box implementation:
- Simplify smart object / elm widget code
- Maybe stop using evas object box altogether
- Implement other layout strategies
@feature
Xavi Artigas
Yeongjong Lee
Yeongjong Lee
Mike Blumenkrantz
Jean-Philippe Andre
Thiep Ha
Cedric BAIL
Tom Hacohen
Carsten Haitzler