David Phillips wrote: > Previously, if failonclear was set to True and a modifier key (especially > shift) was pressed and held in order to modify the next keypress, slock would > detect that a keypress had been made, observe that the buffer was clear and > set the screen to the failure colour. > > 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.
Heyho David, I don't think we should change the current behaviour. As already explained there are two different ways of operation: - The paranoid option / failonclear = true: Here you will leave your screen green and will notice ANY fiddling with the keyboard. Let's say someone assumes he has to press shift 20 times to crash the screenlocker. This will get noticed in the current code state as it will turn the screen red. - The not so paranoid option / failonclear = false: Here the screen will only turn red after a failed unlock attempt. Therefore you would not notice a coworker playing some drum line on the shift key or even on any other key if he resets the buffer before you come back. You propose to make the first option less paranoid, but I cannot see a reason for that. I also don't think introducing another mode of operation is a good idea. We have basically covered both ends of the paranoia range and a third option would just compicate the code. --Markus
