libinput: Support for long press key detection?
spitzak at gmail.com
Mon Oct 27 11:16:16 PDT 2014
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.
More information about the wayland-devel