On Mon, 15 Feb 2016 06:15:07 +0900 Conrad Um <[email protected]> said:
> When items are packed in Box widget, we usually use size hint weight to set > item size proportionately. > If there are two items which don't have size hint min, but the first's > weight is 0.25, and the second's is 0.75, we can guess that they will > divide up box size in 1:3 ratio. > For example, if the size of box is 400px, the first item will have 100px, > the second 300px. > > BTW, Elementary sets item's size hint min internally and automatically. > >From here, difficuty in estimating item size issue occurs. In above case, > if the first item has size hint min value as 125px, but the second doesn't, > can you guess what happens next? > > http://imgur.com/vVZ7P2I > Even though the weight of the first item is 0.25, but it will occupy 193px. > (0.48) > Here is the equation. > ITEM_SIZE = ITEM_MIN_SIZE + (BOX_SIZE - SUM_OF_ITEMS_MIN_SIZE) * WEIGHT > 193.75 = 125 + (400 - (125 + 0)) * 0.25 yes - correct. weight works on the leftover size after min sizes are dealt with. because this math works out nicely and is solvable. having the weight work out as you wnt it to is actually "unsolvable". let me give you an example: box. 400px wide. 2 items in box. item A has weight 0.25 item B has weight 0.75 make minimum width of A be 150px. now what? it's not solvable. .25 of 400px is 100, but item cannot be less than 150px? fail. that's why the sizing algorithms of containers like box and table do the above math. now what if you have 3 items. one with 0.25, one with 0.75, one with 0.5 - does this mean one gets 50%, one gets 75% and one 25% of width? that can't work. at best we can do weights as a SUM (like now) and everyone gets their proportion of that sum. what you want is a different layout algorithm/rule and sure - any container can implement any layout algorithm it likes, but we can't change the current ones and the current ones are actually solvable. :) > You can say that size hint min and weight don't work well at the same time, > so using weight and min is incorrect. Or, they are just "SIZE HINT", so we > can say that we don't guarantee the proportion. no - they work together. weight is the proportion of the EXTRA pixels BEYOND total minimum size that is assigned to this item. how much does it EXPAND by BEYOND its minimum size. :) they work together. just not the way you WANT them to. the way you want is really troublesome to deal with as above. > However the problem is that item size caculations in Evas and Elementary > seem different. (of course logically same but give such an impression due > to automated setting of size hint min in Elementary) hmm not different. min and max size are respected by edje. edje doesn't care about weight (or align) as expanding or not and alignment are done by the edc description. well for swallows. for boxes in evas - i don't remember what it does. i think it may use weight and align like elm as evas_box is used. > If EFL starters try to make relatively arranged items with box, they will > be confused. > The bigger problem is that if there are three items have different min size > but have EVAS_HINT_EXPAND weight (1.0), developers may want to homogeneous > items, but all of them will have different size. that's just not the definition of weight. its above - the spare size beyond min size is divided up by weight. just like box has a homogeneous mode to ensure all items are the same size... you want a different layout mode/algorithm. > If they want all items to have same size, elm_box_homogeneous_set() is > available, but want some of items to have same size, that intention cannot > be realized in current calculation logic. correct - as above. you want a different layout mode. the default mode is this way because its solvable. other modes are unsolvable or much harder to solve. calculating min size is more difficult then. > I cannot find the clear way to solve this, but there can be several > possibilities. > First, crop item if its min size expands over its given size get by weight. > http://imgur.com/pWZYfDe well no - the container min size should expand then to deal with all child min sizes. > Second, expand the entire box to show item fully, and keep ratio. This > might need applying scrollable interface to box to keep original box size. > http://imgur.com/D6cMGiV no - as above. :) > This kind of conflict occurs in applying size hint aspect also. > If EVAS_ASPECT_CONTROL_VERTICAL is set, that means fixing the aspect ratio > based on vertical size, but if there is bigger min width than the value get > by aspect, then which value should be chosen? > http://imgur.com/UXmWZw8 this is another hard one to solve. you end up in unsolvable siutations at times. > Ignore min width? Expand to min width even though aspect ratio is broken? > Expand item size to keep aspect ratio but don't fit vertical size? unsolvable. :) technically the box parent min height then should be 200 as due to aspect fixes and min w of 200, min h thus is implicitly 200... :) > Regards, > conr2d > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
