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.
On Wed, Jul 31, 2019 at 6:13 AM Cedric Bail <ced...@ddlm.me> wrote:
> 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
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Regards, Hermet
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
