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. >
That's the point, that they're not the same object - that there is 'duplication' here even though elem objs 'are' evas objects. Either 'table' should not be in evas, or elem can't have its table widget with certain features. >> 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. > I'm aware of the history of table here.. But "convert elm_table users to evas_object_table"? Well, that'd take a large rewrite of elem and the dropping of the ability to edje-theme the table widget and possibly other stuff. >> 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. > Yes, and that's exactly what ewl and etk also enabled and you in particular argued that such things were not going to be needed if your 'widgets' were evas objects, hence that one should throw away ewl/etk (and related work) and write a brand new gui-toolkit because of the great benefits of having the widget objects be exactly evas objects? And I argued with you that this was largely nonsense. In any case... the point here is that Carsten defined elem to be given in a certain way. It follows more or less the pattern of edje and also copied much of what ewl and etk and e17-widgets had. The elem widgets are all of a single evas object type, namely of type "elm_widget" which is defined via a single generic smart class. It then holds stuff particular to each widget 'type' as particulars to a data pointer held by the generic smart data, and defines its widget 'object' and 'typing' mechanisms according to such extra data. It's roughly an inversion of the ewl and etk approach. In most respects, this is no better or worse than what ewl/etk had, and likely worse for aspects related to 'object', 'type', and 'event' systems. And much worse in terms of api confusion.. You'd be better off eventually *not* referring to any of the evas api. >> If elem objs being evas objects (and exposing the evas and edje apis), >> is such a good idea.. then, in particular, why the above? >> ____________________________________________________________ Nutrition Improve your career health. Click now to study nutrition! http://thirdpartyoffers.juno.com/TGL2141/c?cp=sgQiM36p0DQd45hYMmeEDQAAJ1BkOQx41qXri1ke2A5bHHj8AAYAAAAAAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAAAASQwAAAAA= ------------------------------------------------------------------------------ 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
