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