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? > > > >> 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. > > > >>> 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. > > > > ------------------------------------------------------------------------------ > 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 > -- Gustavo Lima Chaves Senior Developer ProFUSION embedded systems http://profusion.mobi ------------------------------------------------------------------------------ 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
