libinput: Support for long press key detection?

[Carsten Haitzler (The Rasterman)]

On Mon, 27 Oct 2014 11:16:16 -0700 Bill Spitzak <spitzak at gmail.com> said:

> 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.

glut is a pretty primitive toolkit and doesn't do a very large amount of things
most of the full toolkits do, like have any timed infra. you could do it with a
slave thread though.

> > 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.

now you're higher level - compositor. slight problem here is that to do click
cancellation the compositor would need to know the geometry of every clickable
element (button) within every surface at all times. this kind of violates a lot
of wayland design principles. click vs drag is more universal though, but then
we need to creat new event protocols for indicating this "drag begin" event for
instance. another event for "longpressed" etc. - the compositor does have
mainloop infra and thus timeouts don't have to be hacked into threads just to
stuff one into the wrong layer.

> > 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.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com