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...
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 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.
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.
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.
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.
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.
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 :
I think the above discussion of having property on Efl.Ui.Win and Efl.Loop will do for this case.
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 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)
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.
- 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.
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.