On 11/21/2012 05:32 PM, Gustavo Lima Chaves wrote: > * daniel.za...@samsung.com <daniel.za...@samsung.com> [2012-11-21 07:28:27 > +0200]: > > Hi. > > First of all, good work, Yakov et al. Reading and wondering, is NO > INSTANT meaning NO INSTANCE? It means NO_INSTANTIABLE. Maybe we need to write the entire word for less confusion. > > 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. > >> 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. > >>> 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". > >>> 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). > >> We already thought about file_selector_button change, the others were >> not obvious for us. Thank you for the tip. Too, we will create a new >> interface for item management because a lot of classes have the same >> item management operations (behavior is different but a common API can >> be found). >>> As for the overall picture, it seems correct, but I did not compare it with >>> other references so I may have missed something. Great work! :-) >> Sure Glima will find the failures ;-) > Regards, > -- > Gustavo Lima Chaves > Computer Engineer @ ProFUSION Embedded Systems > > ------------------------------------------------------------------------------ > 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
