[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] patch: Evas fill policies
From:       "Gustavo Sverzut Barbieri" <barbieri () profusion ! mobi>
Date:       2008-04-30 23:14:57
Message-ID: b1f2b8c40804301614p4e5450d5u8b65ac1393d14a1c () mail ! gmail ! com
[Download RAW message or body]

On Wed, Apr 30, 2008 at 7:59 PM, Jose Gonzalez <jose_ogp@juno.com> wrote:
>
>
>  > 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.

Just to make clear: what goes into Evas_Object is the hints. They
could be represented as allocated structs managed with
evas_object_data_*(), but since they're so common we could 1) make it
more standard, helping integration and 2) minor optimizations by not
walking the linked list doing strcmp() in order to find these values.
 The integration idea came out after the layout stuff appeared and it
would duplicate lots of stuff into edje, thus having this would help.

All this layout stuff will not go inside evas, but some other library,
either a new one or esmart.

Also, layout is not widgets, but they can be used to provide widgets.
They're regular smart objects that will be provided to avoid code
duplication and help integration. Also, by making it like that and
using standard properties (size hints) we can expose it from Edje
without much trouble.   The big picture is to have this and enable
toolkit integration one day, like be able to mix in the same vertical
list a rectangle, an etk button and a ewl list, this would be really
easy since these (in THEORY!) should expose Evas_Object with all the
properties set.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi
Embedded Systems
--------------------------------------
MSN: barbieri@gmail.com
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

-------------------------------------------------------------------------
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
[prev in list] [next in list] [prev in thread] [next in thread]