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. > 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. > > Best of luck. > > -- > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
