On Mon, Mar 29, 2010 at 2:06 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. >> > > 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.
dude, I really ask myself "should I continue replying to trolling?", but this time it is impossible to not: for once in life, read or use the source before you start trolling! elm_table does not have theme, neither does box... as there is nothing useful to theme in them :-D I'll stop here, as the rest of the mail is as pointless, but I had to troll this as well, couldn't miss that one ;-) -- 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
