Page MenuHomePhabricator

efl_app: add 'exit_on_windows_close' property and unit test
AcceptedPublic

Authored by zmike on Thu, Jan 10, 12:59 PM.

Details

Reviewers
cedric
Maniphest Tasks
T5494: EO: elm policy API
Summary

this property causes the main loop to exit with the passed exit code
when the standby event is triggered

@feature
ref T5494
Depends on D7593

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 8758
zmike created this revision.Thu, Jan 10, 12:59 PM
cedric accepted this revision.Thu, Jan 10, 1:31 PM
This revision is now accepted and ready to land.Thu, Jan 10, 1:31 PM

I somehow don't like to have a function with windows in its name in efl_app.eo efl_app is in the core of EFL, the core of EFL does not neccessarily have anything to do with windows.

How about this function in a config class in the Efl.Ui namespace, which would generate a STANDBY event, on the loop you can decide if you want to exit on STANDBY or not, would sound a bit nicer and cleaner to me, since the two different concernes (Application-Runtime and Action-on-windows-closed) are seperated. Additionally, this design could allow a none UI efl app to use the STANDBY event for the case that no client or so is connected ... :)

I somehow don't like to have a function with windows in its name in efl_app.eo efl_app is in the core of EFL, the core of EFL does not neccessarily have anything to do with windows.

How about this function in a config class in the Efl.Ui namespace, which would generate a STANDBY event, on the loop you can decide if you want to exit on STANDBY or not, would sound a bit nicer and cleaner to me, since the two different concernes (Application-Runtime and Action-on-windows-closed) are seperated. Additionally, this design could allow a none UI efl app to use the STANDBY event for the case that no client or so is connected ... :)

I don't like the side config class concept very much. It is really a side thing that don't seem to match the rest of the infrastructure. I am not sure I also read you correctly, but I think you agree on STANDBY event on the Efl.App object. So the only question is where is this property get/set defined? In that case what do you think if it was a class property on Efl.Ui.Win ?

I don't like the side config class concept very much. It is really a side thing that don't seem to match the rest of the infrastructure. I am not sure I also read you correctly, but I think you agree on STANDBY event on the Efl.App object. So the only question is where is this property get/set defined? In that case what do you think if it was a class property on Efl.Ui.Win ?

You read me correctly. Having it as class function on efl.ui.win sounds actaully not *that* wrong to me (it cannot be on the object, as all objects are defining 1 property, not every obejct 1 property). The reason why i liked the idea of a Efl.Ui.Temp_Config/App_Config is, that we likely will have more config values there, which are right now in elm_config but don't make really sense there, Just a few from my head:

  • A software came definitly wants to have hardware accel, or something that does heavy UI stuff, so you probebly want to have your app beeing accelated, without setting the whole system to hardware accelation
  • elm_config_selection_unfocused_clear_get (also applies to other focus properties) really depends on the UI you have and you probebly don't want to have that behaviour

So i would say that Efl.Ui.Temp_Config / App_Config is just a class to put all those properties instead of putting them in the logical units in the tree. Which goes pretty much hand in hand with Efl.Ui.Config.

So all in all our config concept in EFL would look like:
Efl.Ui.Config <- configs that are loaded / stored into a file on the fs
Efl.Ui.App_Config <- configs that are setted by the app, propebly defaulted by normal Efl.Ui.Config properties, but the setted values are *never* applied to any fs. In general, a place to alter the behaviour of the UI parts of the efl framework.

I don't like the side config class concept very much. It is really a side thing that don't seem to match the rest of the infrastructure. I am not sure I also read you correctly, but I think you agree on STANDBY event on the Efl.App object. So the only question is where is this property get/set defined? In that case what do you think if it was a class property on Efl.Ui.Win ?

You read me correctly. Having it as class function on efl.ui.win sounds actaully not *that* wrong to me (it cannot be on the object, as all objects are defining 1 property, not every obejct 1 property). The reason why i liked the idea of a Efl.Ui.Temp_Config/App_Config is, that we likely will have more config values there, which are right now in elm_config but don't make really sense there, Just a few from my head:

  • A software came definitly wants to have hardware accel, or something that does heavy UI stuff, so you probebly want to have your app beeing accelated, without setting the whole system to hardware accelation
  • elm_config_selection_unfocused_clear_get (also applies to other focus properties) really depends on the UI you have and you probebly don't want to have that behaviour

I am not a fan of the Config interface as it looks really like dropping stuff together as an easy solution. Current elm_policy kind of show that issue. For example, having a window being accelerated, should be the result of a constructor property I think, more than a config things (As it doesn't affect the general default in that situation). I don't know what the other function does, maybe it make sense to have a config for that one, but will have to be convinced. Still in the current scenario, I think a @class function is what we can agree on and move forward with.

So i would say that Efl.Ui.Temp_Config / App_Config is just a class to put all those properties instead of putting them in the logical units in the tree. Which goes pretty much hand in hand with Efl.Ui.Config.

So all in all our config concept in EFL would look like:
Efl.Ui.Config <- configs that are loaded / stored into a file on the fs
Efl.Ui.App_Config <- configs that are setted by the app, propebly defaulted by normal Efl.Ui.Config properties, but the setted values are *never* applied to any fs. In general, a place to alter the behaviour of the UI parts of the efl framework.

I think that could be part of a general overall of our Config interface in Efl.Ui. At this point, I think this is a lot of work to get it right and not critical with the API we are trying to stabilize.