On 11/26/2012 02:44 PM, Gustavo Chaves wrote: > It means NO_INSTANTIABLE. Maybe we need to write the entire word for >> less confusion. >> > I see, cool. > > >>> Why does the Evas class implements the evas_common_interface >>> (evas_get() for an evas handle?)? >> In this way, you can get evas from object without taking care if the >> object is evas or evas_object. >> > But, with an Evas handle why would we want to get its... Evas handle? Well, it is useful if you receive a Eo* and you want to extract the Evas without knowing its type. An example of this could be the creation of an object whose parent is a Eo* (Evas or Evas_Object). You take the parent from an object and you create a new object with that parent. > > >>>> On 11/20/2012 06:55 PM, Gustavo Sverzut Barbieri wrote: >>>>> looking at evas/edje/elm: >>>>> >>>>> - Evas_Object_Smart: shouldn't it be NO INSTANT? Maybe in the future >> when >>>>> people use Eo to create sub-classes as opposed to extending >>>>> Evas_Smart_Class? >>>> We let it for compatibility with existent entities using smart, like e >>>> entities. In my opinion, we need to let it regular for backward >>>> compatibility forever or at least a lot of time. >>> Yeah, I can see problems with existing code, too, but Gustavo's idea >>> is the way to go. >>> >>>>> - elm_widget: NO INSTANT, just compat will be REGULAR. >>>> You are right, will be fixed. FYI no more compat because no one was >>>> supposed to inherit from elm object before the porting. >>> Yep, no instance of elm widget. Compat is long dead, don't worry about >>> it. I'm curious to see these new signal, clickable, zoombable, >>> draggable, selectable interfaces. The idea is good. >>> >>>>> - elm_box should share something with evas box, now that we have eo, >> same >>>>> for table >>>>> - elm_layout should share with edje >>>>> - elm_image, elm_thumb could share with evas_image >>> Ack, ack and ack. >> And I am not sure it is good for code comprehension. You can do a lot of >> good things with object oriented, but you can do disasters too. I have >> seen C++ code simply unreadable. We have to put limits to creativity. >> > We're not talking just 'code comprehension here, but sharing code and being > sane. We got box and table and stuff repeatedly written and spread in these > projects -- merging is the way to go. Simplify the code is good. I just mean that for example, creating a lot of interfaces/mixins can bring to a code that finally will be unreadable and hard to maintain (parameters that are not always the same for all the entities). We need to find the logic optimizations and less "philosophical" ones. > > >>>>> Particularly I think that elm_widget should be an interface and not a >>>>> class, then you compose an elm_image from Evas_Object_Image with >>>>> Elm_Widget. There is no need to have the Evas_Smart as we do have now, >> it's >>>>> just there because we lacked tools. >>> Indeed. With Eo in, we could get rid of Evas_Smart for good, keeping >>> Evas_Object_Smart as a class only until we have no more 'oficial' >>> users of it, and deprecating it ASAP. We could even move the smart >>> virtuals/funcs of evas_object_smart up to Evas_Object, making the >>> smart implementations of rectangle/image etc to link to that internal >> code. >> One day, we thought about that fusion, but as we say in hebrew, "cow >> cow", so let's go slowly because it is not a side change. It is some >> "Small change, big bug". >> > OK, but please commit the planned things on Evas_Object_Smart's code :) > > >>>>> Also some others could be made mixin, file-selector button is both a >> file >>>>> selector and a button to launch it. Same for fileselector. >>> Yep. Some of those could have been made more sane class-hierarchy-wise >>> during my work -- the hell was THEME API BREAKING. Until we can be >>> free to break them, it's hard. >>> >>>>> I know some of my suggestions will require deeper changes and may not >> be >>>>> doable right now, but it's good to keep in mind. >>>> We focused for the moment on the Eo porting without changes on the >>>> design. And I don't want to imagine rebase ;-). >>>> More, we don't have enough deep knowledge to know what is supposed to be >>>> a mixin ... (as you wrote just before) so I think help will be needed >>>> from "outside" to do it. >>> Mmm, I remember Tasn was very confident of its meaning/uses. Also, >>> your image says elm_interface_scrollable is a mixin: what does it mix, >>> coming just from scrollable_interface? >> It contains all the implementation of the scrollable interface common >> functions (i.e what was already there). >> > Still not clear why it's a mixin. How would you have designed it? > >> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > >
------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
