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. 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. 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. 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. ------------------------------------ -Regards, Hermet- -----Original Message----- From: "Tom Hacohen"<tom.haco...@samsung.com> To: "Enlightenment developer list"<enlightenment-devel@lists.sourceforge.net>; Cc: Sent: 2013-09-03 (화) 22:16:40 Subject: Re: [E-devel] [EGIT] [core/elementary] master 01/01: core/elementary - please just mention the fact itself not relative. On 03/09/13 13:39, ChunEon Park wrote: > There are a few differences. > 1. Genlist items have a much shorter life-span than the things you > described above. Which means any issues are much less likely to occur. > -> Genlist users know (or must know) that fact. so it doesn't matter. and > this api is not for only genlist. Why do they must know the internal item recycling policies? 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. > > 2. I'm not particularly fond of the functions above as well. > -> Me neither. but the basic rule is not always true. some cases those kind > apis may be more effective/helpful for users. 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. > > 3. Two wrongs don't make a right, we have done mistakes in the past, no > reason to blindly repeat them. > -> If you can add more correct method to replace them, then i agree they are > wrongs. but you couldn't and nobody did yet. so I belive those APIs are not > all fault. See my reply to #2. > > As for the one I added: I added it after I got sick of exposing > functions all the way between textblock and elementary through edje. > Maybe someone should have stopped me then. > > -> Consequetly, what happened? apps are dead because of the entry? developers > are unhappy because of it? consequently both are happy. > if you should bind all the textblocks stuff for the entry, why didn't u do > it? and actually in that case that was obivous proper solution exist. > acutally we should do it. but the API I added, it doesn't yet. 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. Why didn't I do it? I don't know, I guess because I thought it was even a worse idea, and I was naive enough to think those things I needed the textblock object for will be solved in the future and we'll remove the API. -- 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 ------------------------------------------------------------------------------ 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
