Gustavo Sverzut Barbieri schrieb: > On Fri, May 2, 2008 at 11:23 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > >> 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) > >
A tree shouldn't add much over head. >>> 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. > Again, a widget is not an evas_object. And a evas_object shouldn't become a widget. > 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. > Because a widget is not a top level widget in general. > > >> 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. > You can be sure, I'm living good with that. But you want to tell me that ewl would use evas fill flags if they would already exist. And I can only say, it wouldn't. > > >> 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. > > Yes, I have no problems with the size hints, they are a good thing and I'm sure ewl will set them for the embed smart object in future. But I don't see the point to have the fill flags set by ewl. The user has to set them anyway. So it makes no different if he set them with ewl_object_fill_policy_set(w, EWL_FLAG_FILL_FILL); or with esmart_object_fill_policy_set(embed, ESMART_FILL_FILL); ------------------------------------------------------------------------- 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
