On Tue, 03 Sep 2013 15:37:20 +0100 Tom Hacohen <tom.haco...@samsung.com> wrote:
> Unrelated: please fix your client. > I'm having a really hard time to follow the discussion. > > On 03/09/13 15:02, ChunEon Park wrote: > > Why do they must know the internal item recycling policies? > > > > -> Already genlist mentioned the concept. and if they don't know or they > > dont wanna know this, there is no need to use genlist but list. > > > > * - @c "realized" - This is called when the item in the list is created > > as a > > * real evas object. event_info parameter is the genlist item that was > > * created. > > * - @c "unrealized" - This is called just before an item is unrealized. > > * After this call content objects provided will be deleted and the item > > * object itself delete or be put into a floating cache. > > Yeah, those are a few obscure lines in the documentation no one will > read unless they specifically care about those signals. > > > > > > > Also, > > clarify, where do you plan on using those? Just locally at > > realise/unrealise? > > It doesn't matter if it's not *only* for genlist, if it's available for > > genlist and that's bad, then it's bad. > > > > -> I don't use. and I dont need. Just think the scenario. if user wanna > > create a hover based on the center of the selected item. > > Why are you fighting so hard if you don't really use it or need it? I > can think about that scenario, and the proper solution for that would be > "item_geometry_get", something I think that already exists. > > > > > > Just adding APIs we think are bad reduce the code quality and the > > incentive to fix it and think more about it. > > You obviously need this capability, either because you need it for an > > app of yours, your manager is forcing you, or you just think it's > > needed. Whatever your reason is, that's your incentive to working on it. > > This will disappear the moment you put the "bad" code in. > > > > -> Nobody forced to me. And I don't care of the manger or whatever. I just > > added for users. because i thought it's the negotiated result at this > > moment. It's not just adding API i said, there are no proper/clean solution > > than this. And sure i agree, if there is more effective and clean > > solution code for replacing it. then it's ok remove it. I will agree. > > Re-read what I said. What I'm saying that no better solution will be > sought after as long as there is a solution in. > > > > > I'm unhappy. No apps are dead, because none really use it. We don't really > > have that many apps that use textblock. But they could die, > > unless really really careful. > > -> This is same case. so it needs to warn them those cases. > > Same case in what way? You'd like people not to use the API? :) > > Anyhow, I've said what I have to say, and since everyone (that replied) > disagree with you I see no reason for me to waste more energy on this > matter. > > -- > Tom. Just to be clear, my position was never that I disagreed with this API, it was that I disagreed with the fact that it was now able to be added, without discussion and even after previous iterations of it were removed with the blanket statement of THIS IS BAD AND WE'RE NOT DOING IT. I think it's a useful thing to have, though imo the primary use case is to get the geometry, a specific call for which would also lead to far fewer bugs as a result of frequent item deletion. ------------------------------------------------------------------------------ Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
