(*** This bug was imported into bugs.kde.org ***) Synopsis: unlocking the screen always fails on the first try. Diagnosis and possible fix: Playing around a bit I found that the problem stems from the first key being eaten before it gets entered as part of the password to the dialog box. The probable fix would be to replace a getkey with a peek in the lock screen code that deals with the event handling. This will allow the dialog box to go go to sleep and disappear then on typing the first character wake up but still allow the password authentication to have it too. Workaround: type the shift key to wake up the password dialog then enter as normal EBo --
I don't consider this a bug so I set it to wishlist: it should be quite obvious that the password is only accepted when there's actually a password dialog.
*** Bug 71763 has been marked as a duplicate of this bug. ***
If you say that "it is obvious that the password is only accepted when there's actually a password dialog", it is also obvious that the first key pressed should be passed along to the password dialog if the character can be in a password. So if the shift key is pressed or the mouse is moved, the dialog is simply popped up. However, if I press the space bar or press a "passwordable" character, the dialog should pop up WITH that character already keyed in. XScreensaver implements this behavior, and I find it more intuitive than KScreensaver.
I agree completely. This even used to be the way kscreensaver used to act a long time ago IIRC, and it's a very irritating change that I hate and can't get used to. It reminds me of having to press ctrl-alt-del on windows just to get to the stupid text input. I consider this to be a serious usability issue, not a "wishlist" item.
*** Bug 143626 has been marked as a duplicate of this bug. ***
The lag between moving the mouse or doing anything and the dialogue box even accepting typing input is also problematic. It would be nice for it to instantly start accepting typing in the buffer before it is visible on the first try, or after a passowrd failure.
We could also accept the password without even showing the dialog. That would be nice to confuse people trying to get into your system without permission.
*** Bug 243785 has been marked as a duplicate of this bug. ***
SVN commit 1189445 by ossi: queue up keypresses now you can immediately start typing your password without making the dialog pop up first and then waiting until it has actually done so. FEATURE: 37838 FIXED-IN: 4.6 M +49 -10 lockprocess.cc M +3 -0 lockprocess.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1189445
*** Bug 258548 has been marked as a duplicate of this bug. ***