Page MenuHomePhabricator
Closed, ResolvedPublic


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

Related Objects

zmike created this task.Jan 9 2019, 10:18 AM
zmike triaged this task as TODO priority.
zmike moved this task from Backlog to Evaluating on the efl: api board.Jan 17 2019, 11:09 AM

I don't see any issue with this class.

bu5hm4n added a comment.EditedJan 19 2019, 3:32 AM

Missing API:

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?

We can just make it abstract ... :)

You mean making Efl.App class abstract? Then how do we instantiate it for the user? Do we have an internal eo class that just implement it and use that?

Yes, just a little efl_class_define call, with the abstract as first argument, nothing else. Not ever a .eo file, that should be enough I think ... :)

That is an interesting proposition, that I quite like.

bu5hm4n moved this task from Evaluating to Stabilized on the efl: api board.Feb 21 2019, 10:19 AM
bu5hm4n raised the priority of this task from TODO to Normal.Feb 22 2019, 1:19 AM
zmike closed subtask T7597: efl.loop as Resolved.Mar 11 2019, 10:46 AM
zmike closed this task as Resolved.
zmike claimed this task.