Page MenuHomePhabricator

EO: Support ecore_event APIs
Open, Incoming QueuePublic

Description

Now eo does not support ecore_event APIs.
Since ecore_event APIs does not require object parameter, no class or interface supports ecore_event APIs.

It seems that we need to think about whether we support ecore_event APIs by eo or not and how.
ecore_event APIs are in Ecore_Common.h.

Here is some ecore_event APIs which are not supported by eo and look more important than others.

  • ecore_event_handler_add
  • ecore_event_handler_del
  • ecore_event_add
  • ecore_event_del

Please give your thoughts and opinions.

  • Which APIs should be supported by eo and how to support?

(e.g. class Efl.App or class Efl.Loop should provide some properties.)
(e.g. ecore_event should not be supported. Instead of ecore_event without object parameter, efl_event should be used with Efl.Ui.Win.)

I also think there's missing functionality here, but maybe I don't know how to use the new API.

In commit message 5dd52fd09b7d it suggests that in the future: "Create a message queue per loop and put legacy ecore events on top of it."

So it looks like the idea was that the missing Ecore Events should be emitted by the application's main loop. Anybody in committers knows the state of this work?

There is a bit more information in ecore_event_message_handler.eo:

For Legacy API usage Only                                     
This class is rather hacky/messy as it's really internal glue 
to handle legacy ecore events alongside the new loop message  
stuff merged together. This is ugly as it's internal only     
to quickly glue things together and is destined for death in  
EFL 2.0 or when we dump legacy.
cedric added a subscriber: cedric.Nov 14 2018, 2:42 PM

Why would we need Ecore_Event in Eo ? Do you have use case for it ? Duplicating legacy in Eo API is not a good enough justification in my opinion.

The use case I had in mind was handling app lifecycle events like EFL_APP_EVENT_PAUSE and EFL_APP_EVENT_RESUME.

But now I realize that is already handled in C land and it is only a problem in the C# bindings which are not exposing these app events (no EFL_MAIN_EX() macro).

I'm calling in @lauromoura because this is related to T7204#124649.

Ah, yes, this event are special and you need an early way to register on the main loop.

@segfaultxavi @cedric

I was thinking about app can catch events like android activity catches events.
https://developer.android.com/reference/android/app/Activity#dispatchTouchEvent(android.view.MotionEvent)

Moreover, I was thinking about generating user defined events.
e.g. In legacy, ecore_event_type_new() is used for generating user defined events. ecore_event_handler_add is used for registering user defined event handler. ecore_event_add() is used for emitting user defined event.

@Jaehyun_Cho, regarding your first point, do you want the app to be able to intercepting any event before it is processed by anybody else?
I do not understand what does the Android API regarding events that EFL is missing.

Regarding user-defined events, the new API already allows adding custom events to any Eo object:
https://www.enlightenment.org/develop/guides/c/core/events.md#Defining_Custom_Events
Is this API not enough for your needs?

@Jaehyun_Cho I think this event should either be on the window or on the application object. I don't think we want any of it to go through Ecore_Event.

@cedric welcome back :)
@Jaehyun_Cho

If my memory is correct, this event (= legacy ecore event) had been used by some IOT applications in Tizen.
That is, there were some use cases that applications used none-UI-supports of legacy EFL.
(none-UI-supports are such as loop, network, model (in the future), and so on)

If we don't have any plan to support this with NEW efl, I think "event on window" looks not bad.

@segfaultxavi

regarding your first point, do you want the app to be able to intercepting any event before it is processed by anybody else?

Yes. In android, "activity" handles events before "view" handles it.
The android's "activity" is similar to EFL's "Efl.App" so I wanted to provide a way to let "Efl.App" handles events like the android's "activity" does.

Thank you for the custom events link :)
To support custom events in C# language bindings, I think that we need to provide a way how to set the properties of efl.Event_Description like EFL_EVENT_DESCRIPTION does.
Because the meaning of some properties are not clear to developers (i.e. Name, Unfreezable, Legacy_is, Restart).
Moreover, IMHO "Legacy_is" should not be opened to developers.

@cedric @woohyun

Thank you for the feedbacks :)
Then, let's think about handling events by "Efl.App" when it becomes necessary.

To support custom events in C# language bindings, I think that we need to provide a way how to set the properties of efl.Event_Description like EFL_EVENT_DESCRIPTION does.
Because the meaning of some properties are not clear to developers (i.e. Name, Unfreezable, Legacy_is, Restart).
Moreover, IMHO "Legacy_is" should not be opened to developers.

Hmmm... I was under the impression that C# didn't need to provide custom events because C# classes can use their own event mechanism.
However, you want to create new widgets from C# which should be able to emit their own custom events, so you need to create EFL_EVENT_DESCRIPTION structs. @lauromoura, do you think that is possible from C#?