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