Gustavo wrote: > 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 ;-) >
Dude, saying people are "trolling" is a very easy way to dismiss what you don't want to see discussed. The 'issue' here is whether certain claims and design decisions were reasonable or not, and how this can impact development and developers. If you don't want to reply, that's fine.. not a problem. But spare me the adjectives. Now, as far as table and box not supporting theming.. Sure, they're not implemented to do so now. But they *can* support it, as all elm widgets have a 'hook' for that and you could have that if desired. But whether they do or not is a small part of the general issue here, and either way there's no need to have table and box in both evas (just because that was the easiest way one could see to support those things in edje?) and in elem. ____________________________________________________________ Be a Photographer 2010 is the year to enroll in a Photography Training Program. http://thirdpartyoffers.juno.com/TGL3141/4bb09e205fc862400st02duc ------------------------------------------------------------------------------ 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
