Page MenuHomePhabricator

EO: elm policy API
Closed, ResolvedPublic

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.

For #interfaces I wonder if this should get rolled into efl.config? elm_policy is just "policy" config namespace.

I kind of think that elm_policy is a "hack" as there is no clear API of what value can get in. For the two case I know :

  • ELM_POLICY_THROTTLE
  • ELM_POLICY_QUIT

I think the above discussion of having property on Efl.Ui.Win and Efl.Loop will do for this case.

zmike added a comment.Jan 2 2019, 11:23 AM

It didn't seem like there was a clear decision in the above discussion? Or perhaps I'm just not reading it correctly.

I think there was a clear acceptation of @ajwillia.ms proposal for the Efl.Ui.Win property : efl_ui_win_exit_on_close(Efl_Ui_Win *win, Eina_Value exit_code); .

I would expect the same property on the main loop for when all window are closed along with a new event that only trigger when all window are closed. We have the pause event on the main loop that trigger when all window are either closed or hidden, so just adding some logic to trigger a new event on the main loop plus a property sounds simple and extending what we have nicely. It also doesn't conflict with any binding logic as it doesn't kill the window object, just exit from the main loop.

As for throttle, I think everyone did agree on having that a property on the main loop. Now, I don't think it is something we need right now and this can wait for a later release in my opinion (Very little application are likely messing with that at this point).

zmike added a comment.Jan 2 2019, 11:42 AM

Okay, I'll look into this once my mono build ends...

zmike claimed this task.Jan 7 2019, 6:58 AM
zmike edited projects, added efl (efl-1.22); removed Restricted Project.
zmike added a comment.Jan 7 2019, 11:33 AM

I think there was a clear acceptation of @ajwillia.ms proposal for the Efl.Ui.Win property : efl_ui_win_exit_on_close(Efl_Ui_Win *win, Eina_Value exit_code); .

I would expect the same property on the main loop for when all window are closed along with a new event that only trigger when all window are closed. We have the pause event on the main loop that trigger when all window are either closed or hidden, so just adding some logic to trigger a new event on the main loop plus a property sounds simple and extending what we have nicely. It also doesn't conflict with any binding logic as it doesn't kill the window object, just exit from the main loop.

I've done a very, very rough implementation of this (with unit tests) in P255. Not even going to submit as a diff since it's so rough. Feedback appreciated.

bu5hm4n added a subscriber: bu5hm4n.Jan 8 2019, 6:47 AM

@zmike I pretty much like the draft, i just don't know if it is a good idea to have this property on the loop.
In the end its a ui-bound property, which has nothing to do with the loop,
Maybe its worth having a Efl.Ui.Temp_Config, or App_Config ? Which carries such options, (there should also be the focus options moved)

zmike added a comment.Jan 8 2019, 7:20 AM

Yes, I was thinking the same: this feels more like an app property than a loop property. But I did the implementation based on the above discussion so that we could see how it looks and evaluate it.

Other thoughts:

  • Should the property be on window hide or window delete?
  • How should the app/loop property be named?

Any further changes are not a huge amount of work considering the base logic is already functional, but we should spend some time shedcrafting before I make a real diff.

Quick review of that patch, I think it should be on Efl.App actually. And I also think it should be an event first on the Efl.App (So an application would be able to know itself when all window are closed and act). Logically the logic of the exit on no window left would be done in a handler added on the Efl.App when the exit code is set.

There also shouldn't be a check on the type of the Eina_Value, except for being equal to EINA_VALUE_EMPTY which would disable the behavior.

I would think it should be on window delete, but I am not sure of it really. Not a strong opinion.
What do you think of efl_app_exit_on_windows_close ?

@bu5hm4n we already have a few event on the main loop that are UI related. Pause for example is related to all the window being hidden. This is mostly the case of all the event that manage the lifecycle of the application as they are definitively UI related. I don't think it is a problem as EFL is first a UI toolkit, so having UI related event as part of our main App, is making sense to me. But that's maybe just me.

It feels a bit weird having an event from the window widget to the app object like you are suggesting? Can you give me a use case for applications acting on all windows closed?

The difference between all windows hidden (Pause event on Efl.App) and all windows closed, could be used for example to trim a local cache when the user is unlikely to notice any visual slow down at all (If a window is hidden, it might be asked to popup right away and so doing heavy work might slow coming back up). Other potential example is synchronizing configuration with disk. Things like that.

Okay, that makes sense.

zmike added a comment.Jan 10 2019, 1:03 PM

Gonna close this browser tab now, I've got a good feeling about things here.