libinput: Support for long press key detection?

[Carsten Haitzler (The Rasterman)]

On Sun, 26 Oct 2014 13:10:43 +0100 Stefanie Behme <steffi.behme at gmail.com> said:

> Am 21.10.2014 um 21:03 schrieb Carsten Haitzler (The Rasterman):
> > On Tue, 21 Oct 2014 20:21:26 +0200 Stefanie Behme <steffi.behme at gmail.com>
> > said:
> >
> >> Hi,
> >>
> >> on last ELCE in Duesseldorf I learned that the development of libinput
> >> was started to handle input devices in Wayland compositors. I had a look
> >> in the API documentation and found that the enum "libinput_key_state"
> >> has these values: LIBINPUT_KEY_STATE_RELEASED and
> >> LIBINPUT_KEY_STATE_PRESSED.
> >>
> >> There is a need to detect if a key is pressed (and hold) for a certain
> >> amount of time. If this is the case a long-press key event is send. It
> >> is also possible that several long-press key events are defined for one
> >> key, e.g.:
> >> - 500 ms: KEY_STATE_LONG_PRESSED_1
> >> - 1000 ms: KEY_STATE_LONG_PRESSED_2
> >> - 5000 ms: KEY_STATE_LONG_PRESSED_3
> >>
> >> A long press on a key is e.g. used to create a screen shot.
> >>
> >> Is there any plan to support this kind of long press detection? How
> >> could this look like? Any ideas?
> >
> > can you explain why this needs or  should be done at the libinput level and
> > not in the app/toolkit where it already is handled (at least in some
> > toolkits).
> 
> Since the input handling code was put in an own library to avoid 
> duplicated code I was wondering if long press detection could also be 
> part of libinput. Then this has not to be implemented in every app/toolkit.
> 
> Regarding the answer from Peter, that this would be too high level for 
> libinput, just for my information I wonder where is the border of 
> libinput? Which kind of input handling will be part and which not?

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. they also do press vs
drag handling too with hysteresis. should libinput do this too? then where is
the drag point? n pixels from first touch? at boundary of widget? if there is a
boundary - where is it? often dragging out of the widget cancels the click
action - again widget sets do this. should libinput do it? you are looking at a
long and obstacle-filled slippery slope to put this kind of thing in libinput.

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