On 30/04/14 14:42, Yossi Kantor wrote: > 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?
I know what Elm_Object_Item is used for, and I know it's exposed all around the API. It should, as with anything else we've done be typedefed to Eo *, not Elm_Widget_Item, there shouldn't be that kind of type. > >>>> 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. > Well, my experience about my self and others, and for all I know everyone agrees that motivation leads to better result. I think you might not be 100% honest with yourself with those claims, but if I'm wrong, and you are special in that regard, good for you. It has nothing to do with professional integrity or being a grown-up, it has to do with human psychology. Anyway, glad to see you are a perfect specimen. I really don't feel like arguing this point, so let's just drop it. -- 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
