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

On Thu, 28 Jan 2016 12:42:37 -0200 Brad Luther wrote: Hey Brad, > Say somebody manages to "clamp" any letter or number key without you > noticing, and you for the better of it cannot type in your password > (not because it's all-caps, but because it's spamming lots of

[dev] [sbase] diff3 and beyond?

Is there any interest in having diff3 and beyond (why limit it to anything less than 64, or at all, if implementing it for 3 files) in sbase? pgp4ZEpSZsLiP.pgp Description: OpenPGP digital signature

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

On Thu, 28 Jan 2016 21:02:27 +1300 David Phillips wrote: Hey David, > This patch does not change this. With this patch applied, for someone to > tamper with the shift key and *not* make a change on the screen, their only > option is to press and never release it. This is

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

On Thu, 28 Jan 2016 15:49:54 +0100 FRIGN wrote: > key, until you have not lifted your finger again the screen will stay blue. I mean "black" of course. -- FRIGN

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

Say somebody manages to "clamp" any letter or number key without you noticing, and you for the better of it cannot type in your password (not because it's all-caps, but because it's spamming lots of chars). So we want the screen to turn red on key down? Any key? Why just shift? Not that I care

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

Brad Luther wrote: > Say somebody manages to "clamp" any letter or number key without you noticing, > and you for the better of it cannot type in your password (not because it's > all-caps, but because it's spamming lots of chars). > > So we want the screen to turn red on key down? Any key? Why

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

FRIGN wrote: > So we want the screen to turn red on key down. Heyho, another even more annoying example is: I actually type my password so fast, the key release events are sometimes in the wrong order. You can test it with xev, just type some text as fast as you can and you will find something

Re: [dev] [sbase] diff

I have trimmed down the memory usable a little but, but not reduce the space complexity. (Reduced by 80 % on 32-bit machines, and 88.(8) % on 64-bit machines, as the supreium.) If I understood that algorithm correct, I do not think it will produce the optimal result (I have not look in to it

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

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. >

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

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

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

> Heyho David, Hi Markus > 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.

Re: [dev] [slock] chown to root:root on install?

Hi folks, Quoth Markus Teich: > Nick wrote: > > Ideally slock should always be owned by the root user, so that it can > > disable > > the oom lock. I wonder what the right solution is here, as obviously one > > can't > > chown a file to be owned by root if one isn't root oneself. > > > > One

Re: [dev] [sbase] diff

On Wed, Jan 27, 2016 at 11:22:55PM +0100, Mattias Andrée wrote: > Perhaps I should describe how the program works > (although it is very simple.) The documents are > compared just like of they were words, but with > lines rather than characters, and only add and > remove are valid changes, not

Re: [dev] [sbase] diff

On Thu, 28 Jan 2016 16:48:22 +0100 Markus Wichmann wrote: > On Wed, Jan 27, 2016 at 11:22:55PM +0100, Mattias Andrée > wrote: > > Perhaps I should describe how the program works > > (although it is very simple.) The documents are > > compared just like of they were words, but