Gustavo wrote:
>> 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.
>
>
I understand all this, just mentioning that it may be a good
idea to consider the effects of constantly adding more and more
stuff into "evas objects" which have no real typing mechanism
except a vey primitive one. Smart objects themselves are not done
in a very good way right now - they're very, very useful and whatnot,
but could've and probably should be implemented differently..
especially at the canvas level.
-------------------------------------------------------------------------
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
