Page MenuHomePhabricator

EO: elm policy API
Open, HighPublic

Description

elm_policy API is not bound to EO
This is part of T5301

jpeg created this task.May 16 2017, 7:34 PM

Same applies to elm_language_set.

jpeg added a comment.May 17 2017, 11:35 PM

I believe we need some sort of Application global object here. Do we already have something like that? Such an object could also have the argv list, global properties etc...

Hum, couldn't we use the main loop for that ? We already have we EFL_MAIN macro an automatically registered callback that get the argv as a parameter.

jpeg added a comment.Jun 7 2017, 11:51 PM

The loop is the current thread loop. But I agree this may be sufficient in most cases as those APIs would need to be used from the main loop anyway.

cedric raised the priority of this task from TODO to High.Jul 10 2017, 2:19 PM
jpeg added a comment.Nov 9 2017, 5:51 PM

We can not bind del policies in EO, they must remain for C only.
We need to devise other solutions that work well with bindings that hold strong refs on the windows (C++, C#, JS, ...).
Similarly autodel is no good for bindings...

jpeg renamed this task from elm_policy: Bind to EO to EO: elm policy API.Nov 13 2017, 2:38 AM

My main usecase for this is so that the mainloop exits when the last efl.ui.window is closed - this is true of any language.
I don't understand what is meant by "they must remain for C only".

Maybe this ticket is serving multiple purposes right now?

@ajwillia.ms the issue for bindings is that they have to own the reference of any object that is exposed to their language scope.

If there is a variable with a windows in javascript, that windows can not become suddently undefined. Only if you get out of the object scope or mark it undefined should it become undefined. For C++, if you hold a reference on a window, it should also not become an invalid pointer under your feet.

If we do have a policy that is to destroy windows unconditionnally from the C side with no control from the binding side, then the above problem will show up I think. My current idea is that the policy is an helper that has to be ported in every language. This way we get the proper expected behavior in every language. For making language helper easier, I am thinking of generating a signal on the main loop when the last window is closed and make that part of the life cycle.

jpeg added a comment.Nov 15 2017, 12:18 AM

Basically the elm policy makes C++ applications ERR at best or crash at worst. The same will be true for all bindings, except C :)
Bindings will need a different syntax to implement something like autodel/quit on hide.

jpeg added a comment.Nov 20 2017, 6:54 PM

@singh.amitesh we still need this API to be bound to EO. We should just not have the option to "delete all windows on exit". But the option to "exit when all windows are deleted" is very useful. Throttle has no special impact on bindings.

cedric added a comment.EditedDec 1 2017, 3:10 AM

Got some idea here. If we could define that a window is a "master" window that when close trigger an efl_loop_quit, we actually would cover this use case. I am proposing a new property along this :

efl_ui_win_master_set(Efl_Ui_Win *win, Eina_Value exit_code);

By default the exit_code is set to EINA_VALUE_EMPTY and mean it is not a master window. If set to anything else, it will automatically call efl_loop_quit with that Eina_Value on the window close. The naming can obviously be adjusted. This would allow us to move forward with all our tutorial and make our API usable for the common case.

jpeg added a comment.Dec 4 2017, 2:14 AM

Then policy throttle needs to be a property on the loop or whatever.

What do we do if there are existing objects and efl_exit() is called?

Hi,

I don't know why we need the complexity of master windows now that I think of it. Any window could have this property set - who says that only a master window could cause the app to exit?
What about the following?

efl_ui_win_exit_on_close(Efl_Ui_Win *win, Eina_Value exit_code);

Or for that matter - why expose an API at all? Surely any graphical application will want to exit when all the windows were closed?
We could roll with this be internal only and add something to make it different if requested.

Would anyone else object to setting apps to exit on last window close and just forgetting about this API?
How many times was it used for any other configuration?

jpeg added a comment.Dec 7 2017, 11:11 PM

I agree it should be the default, but there must be a way to make sure an app keeps running after all its windows are closed. Just think of a messenger app for instance, UI may be entirely invisible but its service keeps running. It doesn't have to be 2 different processes. Hmm... I'll think more about it.

Their is an event on the main loop when all window are invisible or closed (pause). Maybe we should make an additional event and have an exit on no window policy on the main loop ?

jpeg added a comment.Jan 15 2018, 6:29 AM

Their is an event on the main loop when all window are invisible or closed (pause). Maybe we should make an additional event and have an exit on no window policy on the main loop ?

Yes that's a great idea! We should add this.

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
bu5hm4n edited projects, added efl: widgets; removed Restricted Project.Jun 11 2018, 9:15 AM
zmike added a subscriber: zmike.

A #Goal ticket should not be set to a milestone.