Re: libinput: Support for long press key detection?
Am 26.10.2014 um 13:35 schrieb Carsten Haitzler (The Rasterman): On Sun, 26 Oct 2014 13:10:43 +0100 Stefanie Behme steffi.be...@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.be...@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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On Mon, 27 Oct 2014 11:16:16 -0700 Bill Spitzak spit...@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)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On 10/27/2014 04:08 PM, Carsten Haitzler (The Rasterman) wrote: 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. Can you explain why that would be needed? I figured if a client cancelled a click it would just ignore the events after that. This would not cause any information to be lost, the client would get all the press/release/move events it does now, so I don't see any reason the compositor needs to know, or if it does need to know then the compositor would need to know this information with the current version of Wayland. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
Am 21.10.2014 um 21:03 schrieb Carsten Haitzler (The Rasterman): On Tue, 21 Oct 2014 20:21:26 +0200 Stefanie Behme steffi.be...@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? Best regards Steffi ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On Sun, 26 Oct 2014 13:10:43 +0100 Stefanie Behme steffi.be...@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.be...@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)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On Tue, Oct 21, 2014 at 08:21:26PM +0200, Stefanie Behme wrote: 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? this would be too high-level for libinput. If you need that functionality, best is to handle it with a timer in the compositor where you also have more semantic information than in libinput. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
libinput: Support for long press key detection?
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? Best regards Steffi ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: libinput: Support for long press key detection?
On Tue, 21 Oct 2014 20:21:26 +0200 Stefanie Behme steffi.be...@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). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
