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
