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. >>>> 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
