On Tue, 12 Jul 2011 19:24:41 -0300 Gustavo Lima Chaves <[email protected]>
said:
for box and table:
ugh. evas box is broken. i distinctly remember having written this to work
properly in the original box code in e...
basically what should happen is this:
1. all children should never be smaller than min size. they should overflow if
box too small for all children (in each dimension).
2. children should never be bigger than max size (unless max size is less than
0 or less than min size) - in each dimension
3. align if >= 0 && <= 1.0, specified where in the ALLOCATED space to that
child the child goes. 0.5 == middle, 0.0 = left/top, 1.0 == bottom/right. if <
0.0 then FILL allocated space with child (but limit to min and max sizes above,
so the allocated space never is less than min or more than max size - with max
size if < min size (or < 0) being unlimited).
4. if all children combined have a min size bigger than parent - overflow
5. if all children combined have a max size less than parent, then align total
content inside using eg box_align settings (same as general align above for
content as a whole).
6. allocated space for child is limited to min and max sizes, with weight
determining how much of the "extra space" the parent has available will be
given to that child based on the sum of all weights of children (in that
dimension) and the weight of that child. ie size = min_size + (available_space
* weight / total_weight) - of course if size > max, then there is more
available space for other siblings and divide accordingly (as that child didnt
use its entire allocation based on weight due to max size limiting).
7. if parent implements padding, then the child min and max size stay as is,
but ADD the padding size around the child min and max size for calculating
space used by child and given to child, BUT child is kept at its min and/or max
size offset inside the space the parent allocates/assigns to it accounting for
padding
8. aspect... ugh. this really maxes life tricky as now width is dependant on
height and height is dependant on width... what i'd say here is that object at
MOST can be in each dimension the size of its assigned size based on the above
but then may shrink in one dimension or the other to use LESS space than is
assigned to maintain aspect hint correctness,.
9. if homogenous is set on a parent we should try and still fill the box
dimensions exactly and TRY make all items the same size. this may mean, if # of
items dont divide evenly into size, making some items 1 pixel bigger (or
smaller) to account for rounding issues.
just looking at evas box... its mucho broken and doesnt follow even basic logic
in situations like yours below.
thats how it should work. ugh. who wants to fix evas box?
> Hi, folks.
>
> I'm writing to gather, specially from Raster and the more ancient Evas
> hackers, what to expect/document about Evas' size hints, WHEN
> COMBINED.
>
> We have some common sense ground here, obviously, like: min/max sizes
> must always be respected.
>
> But if we start to mix, for a given container object, member objects
> having min, max, align, padding and weight hints, things start not to
> be so straightforward WRT defining expected/suggested behavior for
> people implementing objects taking hints for account.
>
> Attached is a simple app. with a *horizontal* box (with geometry
> marked in red) and a child blue rectangle. I've setuped its size hints
> as [min=10,10, max=100,100, align=0.5, padding=30,0,0,0,
> weight=0.0,0.0].
>
> It has commands to set hardcoded sizes on the box ('1', '2' and '3'),
> because it will resize itself after packing objects into it. There
> also a command to toggle weight on/off on that rectangle.
>
> For the 0-weight cases, it layouts as expected. With 1.0 weight, come
> the doubts:
>
> - shouldn't case '1' with weight 1.0 be equal to the case with weight
> 0.0?
>
> - what to do on case '5', here (weight 1.0). Should the size enforced
> on the child match its min. one, also letting it flow out of the
> parent's bounds because of the padding?
>
> Case '3' for 1.0 weight is OK, because the horizontal box won't
> "listen" to y components of weights on children.
>
> So, please, help me sort out what should be the behavior on those two
> cases, so that I can document properly the issue on *combination of
> one or more hints*.
>
> --
> Gustavo Lima Chaves
> Computer Engineer @ ProFUSION Embedded Systems
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [email protected]
------------------------------------------------------------------------------
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
