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
