On Wed, 16 Nov 2011 22:11:53 +1000 David Seikel <onef...@gmail.com> wrote:
> Almost forgot - I never did see any fix for the lua signal issue. > > I've poked at it twice and not gotten anywhere. I don't know enough > about the edje signal and message processing system. Given the > symptoms - that lua gets it's own signals, not those from anywhere > else > - it's likely there is an inverted test somewhere deep in the bowels > of edje. That's just my guess, I can't actually find it. > > For now in my project, messages from C to lua work, but it would be > great if I could use signals instead. Turns out it's a documentation bug. Messages and signals DO the same thing, send information. The docs SAY they do the same thing. "Send an (Edje) message to a given Edje object." "Send/emit an Edje signal to a given Edje object." The ONLY difference is WHAT they send, not WHERE they send it. Yet, there is an undocumented difference. Messages get automatically propagated to sub edje's, signals dont, but have to be explicitly addressed to sub edje's to get there. It just happened that in my project that I was using to reality check my lua additions, the lua group was a sub group of the edje group. So the signals did net get through, coz there's no documentation on what is the magic invocation to get that done. The messages, addressed to exactly the same place as per the docs, did get through. I've heard lots of justification for why that is so, but I don't agree with it. Stuff really should just be consistent, and not push some semantics just coz that's the only way the developer thought of. Fact is that signals are internally dealt with as messages, and just being consistent means more flexibility; smaller, faster code; and less confused developers. The only justification that might save the status quo is - um, we released it already, that MIGHT be an API break. Wasted too much time wading through rasters thick porridge on that. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
