On Tuesday, July 30, 2019 10:12 PM, Hermet Park <hermetp...@gmail.com> wrote: > Since we've driven a lot of use cases calling elm_exit() in the object > event callback via smart objects, > Even we have no guarantees what these smart objects are, because they were > designed to allow custom by services, apps even edje, elm, etc. > If some events calls were immediately triggered, they must be all potential > regression. >
> In Tizen, we faced up about 10 TC broke up due to this and I changed TC > code to work for this. > But I haven't verified how many regression breaks would come up with > inhouse, 3rd apps and services yet. > > If breaks were reported, that's out of my control. Tizen couldn't follow > this changes. Ok, I think I am starting to understand the problem and a potential way to solve it. This seems to be an issue with the couple elm_run/elm_exit. So the logic of not running the next loop should be put inside elm_run/elm_exit. None of EFL code seems to rely on this behavior, so it shouldn't do any bugs in EFL. In Tizen, I am hoping that nobody use directly ecore_main_loop_quit and we can properly document the difference in behavior between the both. It also means that we do not need to reproduce this behavior in EFL unified API. What do you think of that solution? 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
