Page MenuHomePhabricator

efl.input.interface
Closed, ResolvedPublic

Description

| | | |interface Efl.Input.Interface
| | | |├ (P) seat_event_filter
| | | |├ (E) pointer,move
| | | |├ (E) pointer,down
| | | |├ (E) pointer,up
| | | |├ (E) pointer,cancel
| | | |├ (E) pointer,in
| | | |├ (E) pointer,out
| | | |├ (E) pointer,wheel
| | | |├ (E) pointer,axis
| | | |├ (E) finger,move
| | | |├ (E) finger,down
| | | |├ (E) finger,up
| | | |├ (E) key,down
| | | |├ (E) key,up
| | | |├ (E) hold
| | | |├ (E) focus,in
| | | |├ (E) focus,out

Related Objects

StatusAssignedTask
ResolvedNone
ResolvedNone
OpenNone
ResolvedNone
Resolvedbu5hm4n
InvalidNone
InvalidNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
zmike created this task.Jan 8 2019, 11:33 AM
zmike triaged this task as TODO priority.
zmike added a comment.Feb 15 2019, 6:47 AM

This seems like it has some overlap with T7584?

Where? I cannot find any overlap.

zmike added a comment.Feb 15 2019, 8:43 AM
(E) focus,in
(E) focus,out

Oh, I thought to meant "conceptual" overlap, sorry.

Yeah, right there, Efl.Ui.Win implements both interfaces, so a user will never know which one is receiving, or to which one he is subscribing.
Is this wrong, though? Do these two events mean the same thing?

cedric added a comment.Mar 6 2019, 7:34 PM

I can't figure out what are the difference between this two set of focus events. @bu5hm4n do you have an idea?

zmike added a comment.Mar 7 2019, 10:29 AM

It seems like this is the per-object input interface according to some sources.

zmike moved this task from Backlog to Evaluating on the efl: api board.Mar 8 2019, 7:32 AM

I think this is maybe reasonable?

seat_event_filter seems @beta wörthy, the rest looks good to me :)

zmike moved this task from Evaluating to Stabilized on the efl: api board.Mar 11 2019, 10:50 AM
zmike moved this task from Stabilized to Backlog on the efl: api board.Mar 11 2019, 2:57 PM

This requires all the other input classes so it can't be stabilized yet

zmike moved this task from Backlog to Evaluating on the efl: api board.May 15 2019, 10:17 AM

We need to get this done so we can have input events.

This misses all the types of the events.

This misses all the types of the events.

There, just added them.

Thank you :)

zmike added a comment.Jun 12 2019, 6:02 AM

I guess this is okay? I haven't really used it as an API too much (though I've worked on it), but I see that we do have some test cases for it so I guess it's probably functional enough?

bu5hm4n moved this task from Evaluating to Stabilized on the efl: api board.Jun 27 2019, 9:13 AM

What do you think about changing the name of this interface as follows?

Efl.Input.Interface -> Efl.Input.Events
Efl.Input.Event -> Efl.Input.Object or Efl.Input.Event_Object

To be honest, i like the name how it is. The interface here is rather low in the inheritance structure. No API will be named like this the event_prefix is efl_input. Further more, "Efl.Input.Event" implies that it is the content of a event, which is not. Given that, i would pretty much also just leave the name how it is.

Jaehyun_Cho added a comment.EditedJul 11 2019, 7:31 AM

Actually I don't mind the name Efl.Input.Event. It's ok but the reason why I suggested is to change the name "Efl.Input.Interface".

To me, it doesn't look common that the word "class" or "interface" is included in a class name or interface name.

I don't stick to the change from "Efl.Input.Interface" to "Efl.Input.Events". I wish we find better name than "Efl.Input.Interface".

Yeah, naming classes Class or interfaces Interface is bad practice. But in this case, it is not named Interface because it is an interface in the OOP sense, it's because this object represents the physical interface between the user and the program, that is, an input device.
There are a lot of names around this concept (input interface, input device, tool, pointer, finger, key, seat, ...) and we have used all of them in one place or another, so this name is complicated :)

I think I misunderstood the purpose and the meaning of the name.
Now I see the name would be ok :)
Thank you @segfaultxavi @bu5hm4n

Diffusion closed subtask T7965: Efl.Input.Hold as Resolved.
Diffusion closed subtask T7964: Efl.Input.Key as Resolved.
Diffusion closed subtask T7963: Efl.Input.Pointer as Resolved.
Diffusion closed this task as Resolved by committing rEFL1c8f6132af0e: declare a few classes stable.
bu5hm4n removed a parent task: T7902: efl.ui.popup.