Page MenuHomePhabricator

efl_app.eo returns Efl.Loop as a singleton, but not Efl.App
Closed, ResolvedPublic

Description

The property:

@property loop_main @class {
   [[ Points to the main loop instance of the application. ]]
   get {}
   values {
      main_loop: Efl.Loop; [[Application main loop]]
   }
}

Works as singleton, however, it returns Efl.Loop not Efl.App. Which makes it impossible to get a Efl.App object from the POV of bindings.

Is everyone fine with renaming the property to app which returns a Efl.App ?

bu5hm4n created this task.Dec 19 2018, 9:31 AM
bu5hm4n triaged this task as High priority.
bu5hm4n claimed this task.Dec 19 2018, 11:28 AM
bu5hm4n added a subscriber: felipealmeida.

Hum, if you are getting the main loop object, you should be able to do an efl_loop_provider_find on it to get the application. As for returning an Efl.App instead, I guess it would work the same as you can always do a provider_find. So I think it is fine to provide the Efl.App instead. Might make more sense.

@cedric well the efl.app is just inheriting efl.loop so getting Efl.App instead of Efl.Loop is not really a difference, are you fine with the patch above ? This would solve this and allow bindings to use the Efl.App object.

(The patch is bigger than expected in the end, as main_loop which return Efl.App would be weird, so i decided to add app_main ... :)

Also for reference in C, EFL_MAIN expose the Efl.App object directly as parameters in main. I do not know how the initialization of the C# binding is being done actually, but maybe something to investigate. Would be best if EFL_MAIN_EX behavior was also available. I will do the review of the patch right away.

@cedric See my comment https://phab.enlightenment.org/T7204#127190 . There is a POC which implements exactly this behavior :)

However this behavior needs this fix to have a actual Efl.App object.