On 17/10/11 08:20, Carsten Haitzler (The Rasterman) wrote: > On Mon, 17 Oct 2011 08:17:49 +0200 Tom Hacohen > <tom.haco...@partner.samsung.com> said: > >> On 13/10/11 14:11, Carsten Haitzler (The Rasterman) wrote: >>> well here's my take. >>> >>> signals are a generic abstract way to talk with edje. it literally allows >>> edje to even have the whole engine run in another process/thread and handle >>> signals off there. the design allows it so in future we could take >>> advantage of that. but this create complications - like anything (x is a >>> good example as its also async). you could ADD smart callbacks for the edje >>> signals and transition to use those instead within elm_entry. i think this >>> is probably ok. >>> >> >> So should I revert my signal related patches and move to smart callbacks >> then? >> >> As I said, my biggest problem is that now signals and callbacks will be >> "out of order" i.e not in the order expected, are you find with that? > > well thats why i think we can keep signals - or we can use callbacks. but the > programmer has to choose which to use for entry stuff so he keeps things > consistent. use one, or the other. we already have signals for entry changes > and what not - so we need to keep them not to break api.. so we have to > support > them properly. we can ADD smart calbacks inline that allow you to "do more" > more easily. > >
Ok, so I'll keep it in mind for "future changes", this will remain as a signal. -- Tom. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
