these did not even look at aspect hints when calculating sizing. that
means any attempt to set them would lead to... nothing useful. this
handles horiz/vert/both cases (as best as is possible).
@fix
This reverts previous commit and fixes it in the box layout to respect
aspect in elm boxes. note - this probably needs doing in other
containers too like table...
Revert "elm icon/image efl ui image - respect aspect hints at all if set"
Summary:
fw, fh can be referenced in _box_object_aspect_calc
without initialized when ax, ay is greater or equal than 0.
Reviewers: eagleeye
Reviewed By: eagleeye
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11348
Summary:
the mnw and mnh variables were misleading in this context because they actually
refer to the max width and max height
Reviewers: devilhorns
Reviewed By: devilhorns
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl_widgets
Differential Revision: https://phab.enlightenment.org/D6859
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.
Test scenario: ephoto without a recent patch (47fe2b9ab03c151b0f4).
Before any further explanation, ephoto was definitely misusing the
aspect API here. A label most definitely shouldn't be sized based on an
aspect ratio, that's just crazy (you really want to make it as tall as
it's wide?)
If a box has an aspected item, it needs to run its min calc loop twice:
1. Once to determine the "true" min size in the direction of the box
(ie. in X in case of a horizontal box), and
2. Once more in order to apply the aspect ratio to aspected items and
augment the perpendicular min size (ie. Y for horizontal).
After that, it can go and layout the items based on the available size.
As we may guess from the above description (1) determines min W and
(2) determines min H (in horizontal mode).
BUT, there were two problems:
- The wrong item min size was used inside the 2nd loop (the code was
not symmetrical between horizontal and vertical modes). These are the
changes in _smart_extents_non_homogeneous_calc.
- The box min length was based on the actual size of aspected items,
rather than their min size. This goes against the observation. These
are the changes in _smart_extents_calculate.
Ref T5888
@fix
This allows apps to set the objects min size with hint_min,
while letting the rest of EFL define the minimum size with
rstricted_min.
I don't like the property names much...
Mike Blumenkrantz
Carsten Haitzler
SangHyeon Jade Lee
Jean-Philippe Andre
Mike Blumenkrantz
Cedric BAIL