* Yossi Kantor <yossi.kan...@samsung.com> [2014-04-30 16:42:23 +0300]:
> On 04/30/2014 04:07 PM, Tom Hacohen wrote: > > On 30/04/14 13:31, Yossi Kantor wrote: > >> On 04/30/2014 03:16 PM, Tom Hacohen wrote: > >>> On 30/04/14 12:50, Yossi Kantor wrote: > >>>> Hello all, > >>>> > >>>> I have a task of transferring the elementary widget item structure and > >>>> its derivatives to Eo. > >>>> > >>>> Currently there is an internal structure Elm_Widget_Item with its > >>>> internal (and not too heavily used) API. > >>>> All of the classes/structures bellow are directly inheriting from > >>>> Elm_Widget_Item: > >>>> > >>>> Elm_Object_Item > >>>> Elm_Gen_Item > >>>> Elm_Color_Item > >>>> Elm_Ctxpopup_Item > >>>> Elm_Dayselector_Item > >>>> Elm_Diskselector_Item > >>>> Elm_Flipselector_Item > >>>> Elm_Hoversel_Item > >>>> Elm_Index_Item > >>>> Elm_List_Item > >>>> Elm_Menu_Item > >>>> Elm_Multibuttonentry_Item > >>>> Elm_Naviframe_Item > >>>> Elm_Segment_Item > >>>> Elm_Slideshow_Item > >>>> Elm_Toolbar_Item > >>>> > >>>> All of them except Elm_Object_Item are totally private, visible only to > >>>> their specific container. The public access to them is made > >>>> through the Elm_Object_Item, which is basically a wrapper around > >>>> Elm_Widget_Item, providing public and stable API functions to > >>>> the Elm_Widget_Item structure of a desired derived class. Naturally, out > >>>> of protection reasons, not all of the Elm_Widget_Item internal API > >>>> functions > >>>> have representation by Elm_Object_Item interface. > >>>> > >>>> My plan is: > >>>> Make just one base eo class Elm_Object_Item from which all of the > >>>> classes listed above will directly inherit (once eo). This class will > >>>> have the internal structure > >>>> of Elm_Widget_Item (just like now) and public methods and generated > >>>> legacy for all of the interface function Elm_Object_Item has now > >>>> and protected methods for all methods that Elm_Widget_Item API has and > >>>> Elm_Object_Item doesn't. > >>>> Elm_Widget_Item as a name and legacy functions will be removed. This means all widget item hooks will go to /dev/null, right? So much win. > >>>> Elm_Widget_Item legacy functions will be replaced by eo functions calls > >>>> on Elm_Object_Item where needed in the code. > >>>> > >>>> Any suggestions/feedbacks are welcomed. > >>> The way things work there is as follows: > >>> Elm_Widget* like the rest of the EFL is internal and yeah, can be merged > >>> in principle. This is what done with Elm (non item) too. However there, > >>> you guys chose Elm_Widget as the name that stays, so maybe stick to > >>> that. That's a better name anyway. > >> I have to keep the Elm_Object_Item name and not Elm_Widget_Item because > >> the first is public and the second is not. > > We've done differently with Elm, and it's the same case there. You can > > just keep the legacy functions public and keep the class name widget. > > Legacy doesn't dictate how new API is created. > > Elm_Object_Item is a type name used outside the elementary world to > return or refer to items > of containers. It must be there cause external programs call it that. We > might > typedef Elm_Widget_Item Elm_Object_Item, but thats about it. Am I wrong? > > >>> As for the rest, I have nothing specific to say. Just follow what you > >>> guys have been doing with Elm, as that was good. > >>> > >>> Also, I hope you are not only doing it because "it's a task", and you > >>> understand how important this is for the whole EFL. > >> I fail to see the contradiction between something being important and > >> being a task. > > You've also failed to read what I've said. > > > > I never even implied there was a contradiction between the two, I just > > tried to make sure you understand how important this task is because > > from your email it sounded like you didn't really want to do it and was > > forced to. > As for this one, well, my feelings about this are irrelevant for that > matter. > While I'm entitled to my own feelings, opinions and judgments, whether I > speak them > out or not, the quality of my work is unaffected by that. Thats just > professional > integrity. Or beeing a grownup. Either way makes my life great and under > my control. > > Cheers, > > > > -- > > Tom. > > > > > > ------------------------------------------------------------------------------ > > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > > Instantly run your Selenium tests across 300+ browser/OS combos. Get > > unparalleled scalability from the best Selenium testing platform available. > > Simple to use. Nothing to install. Get started now for free." > > http://p.sf.net/sfu/SauceLabs > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > ------------------------------------------------------------------------------ > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE > Instantly run your Selenium tests across 300+ browser/OS combos. Get > unparalleled scalability from the best Selenium testing platform available. > Simple to use. Nothing to install. Get started now for free." > http://p.sf.net/sfu/SauceLabs > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
