* 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? Why does the Evas class implements the evas_common_interface (evas_get() for an 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. > > > > 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. > > > > 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? > 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
