On Sun, Mar 28, 2010 at 4:45 AM, Jose Gonzalez <jose_...@juno.com> wrote: > Gustavo wrote: >>>> >>>> Log: >>>> Make someone else assume responsibility when Elementary is not the >>>> father. >>>> >>> >>> It's a shame to see these kinds of things.. One of the arguing >>> points for elem was that its objs were evas objs. >>> >> >> ???? >> >> There might be two hierarchies, both using evas objects. The first is >> the smart object using member_add/del. Edje uses this for instance. >> The second is elementary and its sub objects, that you use to short >> some search paths, define who will get focus. Guarana, for instance, >> has something similar. There are lots of use cases to have two >> hierarchies, often they will be similar, but this is not mandatory. >> > > There will likely be more than one logical tree of objects > involved in things, since this is a fairly rich setup. Usually > such appear as various subtrees, as there are things that one > doesn't want to expose or count in some way (for example when > things like theming with gfx objects). > > But here we see something a bit different, something due to the > object/type mechanism used by elem 'widgets' vs. that of evas objects > in general (and smart membership is just one particular). > Elem cannot fully wrap all of evas (by design), and conversely > evas' type system doesn't cover elementary's (also by design). > > Let me give you a simple example of what tends to follow from this. > > You defined an evas 'table' object. It's an evas object of type "table". > But there is also defined an elem 'table' widget, and it's also an evas > object, > with widget type also being "table".
They are not the same type, Elementary is one smart object type, at least so far. > But they are not the same evas object, though their behavior and api > are nearly identical and the elem one uses the evas one. ehehehe... elm_table precedes evas table, actually evas table was written based on the same code and once we have effort to convert elm_table users to evas_object_table, we can just remove it :-) Same for box. And these can be defined in edje, which is a big plus, removing layout completely from C. > Much the same goes for the 'image' evas object vs. the 'image' elem widget > (except for a possible additional 'edje'), and for the 'box' obj/wid, etc. well, evas image versus elementary image. They are 2 levels of abstraction, each provide its convenience, just like we have textblock and text, each with convenience and drawbacks (speed, etc). If you look around, all the other systems have the same, maybe they find better names, like "pixbuf" versus "image", but at the end, it is the same as we have: the low level and faster access, the other is the easy to use but more limited. > If elem objs being evas objects (and exposing the evas and edje apis), > is such a good idea.. then, in particular, why the above? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
