On Mon, 19 Dec 2005 12:25:34 +1000 David Seikel <[EMAIL PROTECTED]> babbled:
> On Sat, 17 Dec 2005 18:26:17 +0900 Carsten Haitzler (The Rasterman) > <[EMAIL PROTECTED]> wrote: > > > you need to add the concept of ecore objects. then being able to > > attach things to the ecore objects - that includes keepign the > > callback handler list within the object, not in the global list. so > > now it will walk only the list of callbacks that it will finally be > > calling. otherwise your idea is good - it's just that you really need > > to remove the useless walking as u wont really save much. :) > > That was gonna be my next suggestion. I didn't want to hit you with it > all at once, the email was already too long. I did hint at that though. > > Apart from Ecore_Exe, what other Ecore things will we want to do this > for? not a lot. ecore doesn't have much at all. u have things build on top (ecore_con, ecore_x etc.)... > Since my other recent big email boiled down to "ecore_x's fd handler is > an annoying hack" that might be one candidate which might hide that hack it's like that because libraries liek xlib FORCE it to be. withotu xlib doing unsolicited reads during itsd normal day to day operation, the buffer read callback woudl not be needed at all. the only thing that needs it is ecore_x - for nigh everything else you can entirely ignore it and pass in NULL. :) > locally to ecore_x. That's just bullshit of the top of my head though, > I haven't looked at ecore_x. On the other hand, that is probably > heavily tied to low speed event stuff that the ecore event system > was written for. its tied to xlib doing "unclean" things - thus requiring an unclean interface inside ecore to hide it - and handle any other similar libs that may do unsolicited reads and buffer themselves - this gives the ability to query the libs internal buffer and keep snarfing things form it until its empty. :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
