Page MenuHomePhabricator

DB-SCN: adapt code to Exactness events fix

Authored by JackDanielZ on Nov 29 2018, 5:27 AM.



Only specific events will be candidates to the application generation.
To do this, they need to be specified and typed in config.json.
The only-supported type for the moment is CLICK. It is converted to a

Diff Detail

No Linters Available
No Unit Test Coverage
Build Status
Buildable 8311
Build 7557: arc lint + arc unit
JackDanielZ requested review of this revision.Nov 29 2018, 5:27 AM
JackDanielZ created this revision.

Apply D7386 before this patch.

Please check if this is what you need. For the moment it supported only the clicked event. You can add easily other events in config.json.

YOhoho added a subscriber: YOhoho.Nov 29 2018, 8:20 PM

Hi thank you for your patch.

I think EFL_EVENT should not be removed.
If we apply this patch, we can not create any other events besides the click event.
All event types can not be defined in config.json.

We only need to change the event defined in config.json to custom.
And if it is not defined, it processes it as it is.

I thought that "Klass"->"DB"->"Events"->"clicked":"CLICK" would be efl.ui.button -> DB -> clicked:CLICK and efl.ui.check -> DB -> changed:CLICK.
Some classes that inherit clickable do not necessarily use clickable.
For example, maybe? there is a checkbox.
I think we need to define each of them according to the events used in each widget.

What do you think?

AND :)

@YOhoho is worried about some events being replaced by clicks.
because there may be cases that the event is called directly by callback_call.

So he suggested. When you call callback_call and create an event in the ML, ml_gen display what action it was created from.
For example
on changed[click] {...}
on changed[key] {...}
on changed[call] {...}

But we do not know what action is do when callback is called.
This is currently not possible,
But generating each action randomly in a scenario when doing scn_gen seems to be a good way to increase test coverage.
ML and DB generated from that scenario can have multiple actions for one event.

What do you think about this suggestion?

Hi guys,

I removed EFL_EVENT because I didn't find in the MLs written by the spy any event that would be really required by the user, except things related to the mouse and the keyboard. Mouse events are supported by CLICK_ON event, as we want to click on a specific widget and we don't know its position and size. Keyboard will be supported by the already existing KEY_DOWN/_UP as they are not specific to a widget (we may need to click on the widget to put it on focus so the keys are sent to the widget).

Concerning the config.json, you cannot have a check box registering for a such event if it is not in the MLs as they are the reference for the DB. I understand the point where you may want a specific behavior for a specific widget. So the generator can check if the wdg_class->DB->Events... exist and then if the event_class->DB->Events... exist. In your example, first we check if Efl.Ui.Button...clicked exists OR if Efl.Ui.Clickable...clicked exists.

Concerning @YOhoho troubles :-), as you mentioned, the spy cannot know where it comes from, as the Exactness player triggers the event, not the spy.
@Junsu, so you suggest to create events on widgets, no matter if they can receive it or not?

  • click and keyboard on whatever we want
  • call with EFL_EVENT if some event is supported by a widget

I don't know if it will give good results, as we will send events on widgets that don't expect to receive such. And then, which callbacks do you create on these widgets? clicked, changed, selected?

jsuya added a comment.Dec 3 2018, 12:09 AM

I think EFL_EVENT is necessary.

If i want to add an event for checkbox based on your patch, i should do something like this:

"Efl.Ui.Nstate": {
   "DB":    {
      "Events":       {
         "changed": "CLICK"

If i want to add an event for elm_list

"Efl.Ui.Selectable": {
   "DB":    {
      "Events":       {
         "selected": "CLICK"

Of course, we can write all the events to be replaced with "CLICK".
Most events that can be imported from an EA file may enough to be changed to "CLICK".

But please check attached file.(Search results from ea files)
There are expanded, contracted, realized, delay,changed etc..

If other events are hooked, they will be needed.
I think that events that can not be handled by mouse or key input necessarily exist.

Currently there is no action to call that event. So it may not be useless.

We can consider and add the scenario customization feature someday.
Then we will think about events that are in ML but not created.

And as you understand

"Elm.Button": {
   "DB":    {
      "Events":       {
         "clicked": "CLICK"
"Elm.Checkbox": {
   "DB":    {
      "Events":       {
         "changed": "CLICK"
"Elm.list.item": {
   "DB":    {
      "Events":       {
         "selected": "CLICK"

I think we should do as I wrote above.
I think it's easy to create a specific action for a specific widget.

But this is just my opinion.
You do not have to do this unless you agree.

Bring back Efl Event

jsuya accepted this revision.Dec 3 2018, 8:41 PM
This revision is now accepted and ready to land.Dec 3 2018, 8:41 PM
JackDanielZ closed this revision.Dec 4 2018, 6:13 AM