No, actually I ran into it again just a week ago, when I discovered it I was like "gaaaaaah not THAT agaaaaaain". I "fixed" it by adding a 1s delay to the signal that had to happen last, but I don't really like that solution because it's really hackish. As I said, you're going to run into it when you do some signal propagation (which we do because our application is one big edje file), the only solution would be to change the way edje handles signals (replace the queue with an execution tree), but that would be lots of work and a really big change to the way edje works
On 11/17/10, Gustavo Sverzut Barbieri <[email protected]> wrote: > Hi Hugo, > > Did you fix or solved this problem somehow? > > On Tue, Aug 10, 2010 at 5:37 AM, Hugo Camboulive > <[email protected]> wrote: >> Hi, I noticed a serious problem with Edje execution queue. >> I use signals to send messages down to subgroups (since you can't do >> PART:"subgroup:part" in embryo), but problems occur when there are >> more levels of signals. >> Let's imagine, you have two actions, first show something, then hide >> >> script { >> emit("subgroup:show", ""); >> emit("subgroup:hide", ""); >> } >> >> now, in the subgroup you have >> program { >> signal: "show"; >> script { >> set_state(PART:"foo", "shown", 0.0); >> emit("subsubgroup:show", ""); >> } >> } >> program { >> signal: "hide"; >> script { >> set_state(PART:"foo", "hidden", 0.0); >> emit("subsubgroup:hide", ""); >> } >> } >> >> What you would expect when you programmed it, is this order : >> - emit("subgroup:show", ""); >> - caught by subgroup >> - set_state(PART:"foo", "shown", 0.0); >> - emit("subsubgroup:show", ""); >> - caught by the subsubgroup, which does whatever it needs >> - emit("subgroup:hide", ""); >> - caught by subgroup >> - set_state(PART:"foo", "hidden", 0.0); >> - emit("subsubgroup:hide", ""); >> - caught by the subsubgroup, which does whatever it needs >> >> What happens really is : >> - emit("subgroup:hide", ""); QUEUED >> - emit("subgroup:show", ""); QUEUED >> - execute subgroup:show >> - set_state(PART:"foo", "shown"); (is it queued or executed?) >> - emit("subsubgroup:show"); QUEUED >> - execute subgroup:hide >> - set_state(PART:"foo", "hidden"); >> - emit("subsubgroup:hide"); QUEUED >> - execute subsubgroup:show >> - ... do whatever it does >> - execute subsubgroup:hide >> >> So instead of having "all the commands that written on the next line >> is executed after", we have "the commands with the more depth (if we >> see this as an execution tree) are executed last.". Which means some >> "show" commands are executed after "hide" commands, quite a surprise! >> (ok, in this example everything ends well because the actions of hide >> and show are symmetrical, but it's not always the case) >> >> If you have an execution tree like this (let's hope the graph survives >> emailing) >> A >> / \ >> B E >> | / \ >> C F G >> | >> D >> the execution order will be A B E C F G D (if you execute those >> commands using emit() ) >> the execution order will be A B C D E F G (if you execute those >> commands using run_program(), which unfortunately you cannot with >> programs in sub groups. This is the kind of order you get when calling >> functions in C for example) >> >> It gets even worse, because the behavior becomes dependent on timing, >> see this example : >> collections { >> group { >> name: "main"; >> programs { >> program { >> name: "A"; >> signal: "main"; >> script { >> emit("A", ""); >> } >> after: "C"; >> } >> program { >> name: "C"; >> // in: 1 0; >> script { >> emit("C", ""); >> } >> } >> program { >> name: "B"; >> signal: "A"; >> script { >> emit("B", ""); >> } >> } >> program { >> name: "D"; >> signal: "C"; >> script { >> emit("D", ""); >> } >> } >> } >> } >> } >> >> Wether or not you comment the "in: 1 0;" line, you will get a signal >> order of { A C B D } OR { A B C D }, this can get really ugly and give >> surprising behaviors >> >> I'm not sure how to fix this. >> In an edje program, the only way to get the expected behavior would be >> to put all "important" stuff in leafs, and add placeholder signals in >> between so that all the leaves are at the same depth. Ugly hack. >> The other solution would involve changing Edje to queue the signals >> right after the current execution point in the queue, instead of >> putting them at the end of the queue. (well if you don't add them at >> the end, it's not really a queue anymore, but anyway...), but that >> would be a big change. >> >> Now, maybe I'm wrong somewhere, but I think this problem prevents from >> doing anything more than trivial in Edje scripts. Combined with the >> un-ability to do a PART: or PROGRAM: with a subgroup element, it can >> become a serious problem for an Edje developer. Maybe Lua fixes this, >> but last time I asked it was still being rewritten. (is it?) >> >> Any idea? I'm in a dead end here. >> Sorry for the overly long post and the not-so-clear examples >> >> Hugo >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> enlightenment-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: [email protected] > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
