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
Jean-Philippe Andre
Carsten Haitzler
Mike Blumenkrantz
Cedric BAIL