On Fri, May 2, 2008 at 11:23 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Gustavo Sverzut Barbieri schrieb: > > > > 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 > > > I don't see where they are "so common". Sure every widget set use this or a > similar concept for fill policies, but for widgets and not for evas objects.
edje, to name one e, non-widget, library that uses it... also, almost every program I've written uses this in a way or another. > > 2) minor optimizations by not > > walking the linked list doing strcmp() in order to find these values. > > > > > You can use a hash or a tree instead. sure, but then you waste almost a kb on the bucket allocation. it's a trade off, no free lunch. (btw, yes, evas speed up this by keeping the hot elements at the beginning) > > The integration idea came out after the layout stuff appeared and it > > would duplicate lots of stuff into edje, thus having this would help. > > > > > What I have read is that raster wants this layout stuff anyway in edje, so > you can reuse it there. sorry, but this will be what Edje will use to provide its, so it's lower level than edje, edje will export it if available. > > All this layout stuff will not go inside evas, but some other library, > > either a new one or esmart. > > > > > Right and that is the weak point of the whole thing. Why putting all the > getters and setters into evas, if evas has no concept to deal with the > values? If you need the callback infrastructure you can probably extend > evas_object to support custom callbacks. And as you said you can already > attach data to evas_objects. the point is a common interface to set these hints so others can interact the same way. imagine one day ewl and etk supports that, you can use the layout machinery to place elements from both tk without trouble. or you can mix them if needed. the whole point is: this should be in Evas (or official E libs) way before, if both hints and layouts were there before these libs would be already using it, maybe built with that in mind, making it easier to integrate. > > 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. > > > > > > You can already mix them if you want this. Just put your widget(s) into an > ewl_embed or in an etk_embed (or however the etk counter-part is called) and > put them into a esmart_container. why this requirement? given the way evas and edje work, this should be transparent at least. Also, by having ewl_embeded or etk_embeded, how did you get the hints communicated? you don't. > In general, i think, you make the assumption that a widget is an evas > (smart) object plus some other values that are needed to manage them. But > this is not true, at least for ewl. An ewl widget that is off-screen or > hidden will not have an evas object at all. that's ewl design, you have to live with that, not me. > So even if we would want to, we cannot re-use this flags. You can, for example, copy ewl hints/policies to evas_object when you return it from ewl_embeded, you can check these properties on evas_object and copy them to ewl when you add some object to canvas. You'd not use _JUST_ that, but you can benefit from that. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] 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
