Re: [dev] [PATCH] [slock] React to key release rather than key press events

From: Eric Pruitt <eric.pruitt_AT_gmail.com>
Date: Sat, 20 Aug 2016 18:05:58 -0700

On Thu, Jan 28, 2016 at 07:20:12PM +1300, David Phillips wrote:
> That behaviour is unwanted if the first key in a password is 'shift'.
> The new behaviour will still turn slock to the failure colour if the
> shift key
> is pressed, but only once it is released and the buffer is still
> clear.

I wrote a variant of the patch which is attached. It works well with
"failonclear = 1", and I think it addresses the problems mentioned in
this thread. It modifies slock so modifier keys that are depressed
without a complementary key only cause the screen to show the failure
color once they're released, and it only does that after at least one
key is pressed after launching slock; if you have slock mapped to, say,
Ctrl+Shift+L, it won't turn $FAILURE_COLOR when you take you lift your
hands off the keyboard. To hopefully clarify, here are a few examples:

A:
1. Shift pressed down
2. Shift released
3. Screen turns $FAILURE_COLOR

B:
1. Shift pressed down
2. "a" pressed down while Shift is still down
3. "a" and Shift are released
4. Screen turns $TYPING_IN_PROGRESS_COLOR

C:
1. Screen is unlocked
2. User presses Ctrl+Shift+L to lock screen
3. slock shows $NO_ACTIVITY_COLOR.
4. User removes hand from keyboard.
5. slock color does **not** change

Eric

Received on Sun Aug 21 2016 - 03:05:58 CEST

This archive was generated by hypermail 2.3.0 : Sun Aug 21 2016 - 03:12:11 CEST