On Tuesday, July 30, 2019 5:00 AM, Hermet Park <hermetp...@gmail.com> wrote: > We have to notice that user could build up a lot of objects before main > loop begin, > Now they have to put very ugly conditions for this change. >
> Though we think previous code is a bug,
> Users won't agree, they might think this is due to just unstable efl
> changes.
>
> some_event_cb()
> {
> ...
> if (main_loop_not_begin_yet) direct_exit = true;
> else elm_exit();
> }
>
> main_func()
> {
> direct_exit = false;
> main_loop_not_begin_yet = true;
>
> ...
>
> if (!direct_exit) elm_run();
> main_loop_not_begin_yet = false;
>
> ...
> }
I am not sure I understand this code snippet correctly, but basically some
object are create with an event handler on them. The event are called before
the main loop is started, and the user want to actually not start that loop.
The user seems to be relying on an undocumented implicit behavior where exit
from the main loop when it was not running cause an exit from the next attempt
to run the main loop. A code like this is indeed hard to debug, as when you
read it, you see elm_exit and you could be thinking that it would be running in
the main loop. At least when it is explicit, you know that this event could be
run outside of the main loop.
It is my opinion here and people using our API might disagree, but I think that
when I read code I get expectation of the context it is running in. Typically,
if I see a code that exit the main loop, I will assume that the context of that
function is to run in the main loop. Otherwise the complexity of understanding
large piece of code become problematic. Assumption are necessary.
I would hope people do not write code that is that confusing, but anyway in the
context of unified interface, we are always in the main loop, so this confusing
construct will be gone.
The question that remains are how many applications do rely on this implicit
behavior? Do we want to be bug compatible with it forever? Are we ok having it
in our code base considering that it does create a good amount of bugs in our
tests?
Cedric
publickey - cedric@ddlm.me - 0x1869A77F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
