Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
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=sgQiM36p0DQd45hYMmeEDQAAJ1BkOQx41qXri1ke2A5bHHj8AAYAAADNAAASQwA= -- Download Intel#174; Parallel Studio Eval Try the new software tools for
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
Gustavo wrote: On Sun, Mar 28, 2010 at 4:19 PM, Rui Miguel Silva Seabra r...@1407.org wrote: Em 28-03-2010 14:37, Gustavo Sverzut Barbieri escreveu: 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. Does this mean that we should generically s/elm_table/evas_object_table/g I'd recommend a more EFL, efficient and flexible approach: add your layout as Edje, inside it define parts of type BOX or TABLE, then in elementary: layout = elm_layout_add(parent); elm_layout_file_set(layout, file, group); edje = elm_layout_edje_get(layout); then, with edje, you just call pack, append or similar methods. But padding, alignment and all are all up to theme. I used this with netbook-launcher-efl used by Ubuntu and the result is AWESOME, you can have themes so different, with one having a vertical and the other an horizontal list, just by defining the list as BOX and adding it inside a scroller. :-) Why bother with apis like edje = elm_layout_edje_get(layout) when one really just wants to have this 'layout' exhibit some (but not all) of the edje lib's api. Just expose the desired functions as elm api functions dealing with the 'layout' widget itself. Love Spell Click here to light up your life with a love spell! http://thirdpartyoffers.juno.com/TGL2141/c?cp=nxftgfBWd5j_VnojKS9sGwAAJ1BkOQx41qXri1ke2A5bHHj8AAYAAADNRwA= -- Download Intel#174; 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
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
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:
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
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 ;-)
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
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. But they are not the same evas object, though their behavior and api are nearly identical and the elem one uses the evas one. 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. If elem objs being evas objects (and exposing the evas and edje apis), is such a good idea.. then, in particular, why the above? Hotel Hotel pics, info and virtual tours. Click here to book a hotel online. http://thirdpartyoffers.juno.com/TGL2141/c?cp=ayO2nx1SAdV5mpUOB7XHmgAAJ1BkOQx41qXri1ke2A5bHHj8AAYAAADNAAATRAA= -- Download Intel#174; 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
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
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#174; 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
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
Em 28-03-2010 14:37, Gustavo Sverzut Barbieri escreveu: 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. Does this mean that we should generically s/elm_table/evas_object_table/g ? Rui -- Download Intel#174; 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
[E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
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. Small Business Tools Compete with the big boys. Click here to find products to benefit your business. http://thirdpartyoffers.juno.com/TGL2141/c?cp=mwMdoXkZsdkXyNYsGb33OgAAJ1AoRuPvi1GlvaxaES1XTMe4AAYAAADNAAARMQA= -- Download Intel#174; 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
Re: [E-devel] E SVN: sachiel trunk/TMP/st/elementary/src/edje_externals
On Fri, Mar 26, 2010 at 8:46 AM, Jose Gonzalez jose_...@juno.com 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. BR, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Download Intel#174; 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
