libinput: Support for long press key detection?

[Stefanie Behme]

Am 26.10.2014 um 13:35 schrieb 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.


Ok, I see. Many thanks for your help!

Best regards

Steffi