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.