class Efl.App ├ (P) app_main ├ (P) build_efl_version ├ (P) efl_version ├ (E) pause ├ (E) resume ├ (E) terminate ├ (E) signal,usr1 ├ (E) signal,usr2 ├ (E) signal,hup
|Open||None||T7510 evaluate stabilization potential of efl.ui classes and dependencies|
|Resolved||None||T7514 efl.app / efl.loop|
|Resolved||ManMower||T7657 Remove Efl.Io.* interfaces from efl_task|
eolian: efl_app.eo:3:1: unimplemented function 'close_on_exec' (originally defined at efl_io_closer.eo:52:13) eolian: efl_app.eo:3:1: unimplemented function 'close_on_invalidate' (originally defined at efl_io_closer.eo:68:13)
Quoting from T7514
- arguments event should probebly be here instead of in efl_loop
- Construction should not be possible from API-land
We should think about a namespace ?
- The reason argument is in efl_loop is because of the thread model design adopted. Moving it over here would break it, I think.
- How can you prevent a class from being constructed from the API-land side? We could make it mandatory to call a private function in the constructor to do so. Is it really a behavior we want to push forward?