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