Overall: this seems like the object which is used to represent any kind of pointer-event, undepended from pointer,move click or wheel changes.

Source should have Efl.Gfx.Entity as src type not Efl.Object i guess ?
Should we replace button_flags with a int, more than a double or triple click can happen, i don't know why we have this restriction. Should we replace the tool int with something meaningfull ? We only pass there in a test 0-3 in, and i don't know whatever this means.

I think button_flags is just mimicking the existing evas info. The point of this is that EFL only handles up to a triple click and anything beyond that is up to the user.

Tool I think is supposed to be like the X11 property from XI2? Most of EFL's input architecture is just copying X11 mechanics.

Okay, i think we should drop tool here. There is device_type on the Efl.Input.Device which is accessable via Efl.Input.Event.device. This would resolve this issue.

My argument with button_flags still stands, i think its very limitting, and confusing that after 3 clicks its again 0 clicks.

Okay, after a while of searching and reading it appears the the integer "tool" is telling the number of the pointer down event, in case we have multiple down touches on the window. Should we rename tool to multi_counter?

I think i would leave value and value_has under beta for now, this concept looks weird, we can see if it is needed or not.

@bu5hm4n
I totally agree with you about value and value_has..