libinput: Support for long press key detection?

[Bill Spitzak]

On 10/26/2014 05:35 AM, Carsten Haitzler (The Rasterman) wrote:

> to implement longpress you need to implement timeouts - this is where it begins
> getting high level and far more hairy than libinput is. toolkits already do
> this and have timeout infra with their mainloop handling.

That's not always true, especially for very simple toolkits (GLUT for 
example), and for demo code that shows how to use a window system api.

> Should they also do press vs
> drag handling too with hysteresis.

I think having the compositor do this would be an excellent idea. 
Currently it is very annoying that the rule for switching from click to 
drag varies somewhat between applications. "hover" detection and whether 
a click is a "double" would be immensely useful too. And get keyboard 
repeat in there too.

You are right that libinput should not do this. I see it as something 
the compositor does. It is just like the gestures for touch.

> Then where is
> the drag point? n pixels from first touch?

Yes. The rule for sending a "drag started" event is some integration of 
mouse motion and speed and second and third derivatives exceeding some 
threshold. It also needs to be per-device, some of them may be able to 
include pressure or other controls.

> at boundary of widget?

No, obviously not. If the client gets a "drag started" event, it is free 
to remember that fact and not do anything about it until it gets motion 
outside the widget.

> often dragging out of the widget cancels the click
> action - again widget sets do this.

Of course the client does this. When the mouse goes outside the widget 
it stops dragging. Compositor does not care. Any feedback such as 
changing the cursor is done by the client.

> should libinput do it? you are looking at a
> long and obstacle-filled slippery slope to put this kind of thing in libinput.

I see it as immensely simpler than the api to communicate user 
preferences for this stuff to clients, which is going to be required if 
multiple seats and outputs and remote desktops are used.

Also "gestures" are already being done this way. The mouse and keyboard 
should not be different.