> As we discussed at IRC, probably this policies can be handled on top
> of currently existing Size_Hints and no other members should be added
> to the struct.
>
> Also agreed at IRC is that most difficult part is to get all the
> requirements written, we should start with V/HBox as they're useful
> and easier to write. We'll do this in wiki (with you sending the URL
> as soon as you get it started!).
>
> We need to figure out what hints to use, if they will be enforced or
> not or depends (configurable) and how to act when layout object
> (parent) geometry is larger or smaller than the requested/possible by
> the children and also the same about children within space when in
> homogeneous mode. A list would be:
>
> Hints to use (first draft):
> - min = max = request => no expand/fill
> - max = request = infinite => expand
> - max = infinite => fill (?)
> - maybe add more values for aspect_mode?
>
> How to lay out children within the self geometry:
> - {v,h}align from 0.0 - 1.0 to align the box composed of all
> children objects and spacing/margins. If children+spacing box is
> larger than current geometry it would overflow to the other side.
> ie: halign = 0.0 (left) would overflow to the right.
> - maybe consider -1.0 a value to "spread" (like text's
> "justify")? in the case of children+spacing not fit self geometry,
> don't overflow at either side, have them to overlap if required?
> - Other requirements?
>
> Homogeneous setups: this case is much like the reduction of the "how
> to lay out children within the self geometry" with one child. That is,
> the area to allocate for the child is what "self geometry" used to be.
> In this case we might have {v,h}align for each object as well?
>
> e17/apps/e/src/bin/e_box.c does most of that like I proposed, but it
> doesn't use any size_hints, as it was not available at the time.
>
>
> This also helps to see that it's usual to have [vh]align property.
> Edje uses this for every part, layout will use it. Maybe these
> should go as a hint in Evas_Object? Won't it be an impact on memory
> usage adding 2 double per object? let's remember many objects (ie
> clippers) will not use it. Also, I'm planing to move the size hints
> struct out of Evas_Object and have a pointer to it that would be lazy
> allocated when user set the value. If [vh]align would be desired in
> Evas_Object but the problem is struct size, this might help.
>
One of the things I see going on with this kind of thing is
an attempt to put more and more 'widgetry/layout' kinds of needs
into evas objects in a generic way. The 'problem' with some of this
is that evas objects don't have any real notion of 'inheritance' or
other sub-typing mechanism, and putting more and more of this into
evas in a generic way, though it's useful for many, many kinds of
things, also presents a potential source of 'issues', confusion,
conflicts, etc.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
