Summary: | Screen always locks (requires password) even if not supposed to | ||
---|---|---|---|
Product: | [Unmaintained] kscreensaver | Reporter: | bill p. (aka google01103) <dweeble01103> |
Component: | locker-qml | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | 369start, abrahams, annma, eugene, gordon, hrvoje.senjan, jef_pera, jjm, jtamate, kaysimon, leibaokai, lmenut, mfraz74+kde, mmtsales, oliver.henshaw, simplew8, stupor_scurvy343, tim, wstephenson |
Priority: | NOR | Keywords: | regression |
Version: | 4.9.80 Beta1 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | http://commits.kde.org/kde-workspace/72ca24bb6484b014ea4d91a323b8a7c8a44085aa | Version Fixed In: | 4.10.1 |
Sentry Crash Report: | |||
Attachments: | Patch for smoothing |
Description
bill p. (aka google01103)
2012-11-29 12:26:31 UTC
indeed, the password dialog is always started / shown no matter the setting. also the password field should be focused, currently it needs to be selected Just to re-enforce that the password filed does not get focused but i dont know it it would be better to create a different bug report or if it can be handled here. Some feedback would be appreciated. not fixed in beta2 *** Bug 311434 has been marked as a duplicate of this bug. *** A couple of other things I've noticed are that the password dialogue appears just before the screen saver starts up and if you move the mouse just after it has activated the screen saver crashes. Confirmed in KDE 4.10 beta2, marking as regression. *** Bug 311596 has been marked as a duplicate of this bug. *** still occurring and as we are in 4.10rc1, will this be resolved by final? *** Bug 309702 has been marked as a duplicate of this bug. *** KSldApp needs to be taught to respect the Lock boolean from kscreensaverrc - if the screenlocker is set not to require a password then the grace period should extend indefinitely. It's not quite as simple as I first thought though: in the new locker is looks like the grace period is only meant to start when the screenlocker is activated on idle, not in other situations (may not be a conscious design choice though). I need to check how the old screensaver locker acted in various situations to see what the correct behaviour is. Still occurring in 4.10 Final, did anybody noticed about it? Yes, this annoying bug is still present in 4.10 final. However I just applied Oliver Henshaw's patch and it works. Git commit 72ca24bb6484b014ea4d91a323b8a7c8a44085aa by Oliver Henshaw. Committed on 11/01/2013 at 21:04. Pushed by oliverhenshaw into branch 'KDE/4.10'. Respect Lock boolean in configuration If not set to require password, don't start the grace period timer and always consider in grace period. REVIEW: 108425 FIXED-IN: 4.10.1 M +7 -1 ksmserver/screenlocker/ksldapp.cpp http://commits.kde.org/kde-workspace/72ca24bb6484b014ea4d91a323b8a7c8a44085aa *** Bug 312833 has been marked as a duplicate of this bug. *** latest update to 4.10 appears to have fixed this I've updated to 4.10.1, and the "password is always required" issue is indeed fixed. You do no longer have to enter your password, if you didn't check that option. However, there are still a few issues remaining unchanged in 4.10.1 (I already wrote about them in my bug report here: https://bugs.kde.org/show_bug.cgi?id=312833) - When the timeout for the screensaver is up and the screensaver is launched, the screen lock dialog is *still* displayed (with the 4.10 default wallpaper as background), with the screensaver running on top of it. The screenlock dialog should only be displayed when the "password required" option has been checked. - The very first time the screensaver is launched by timeout after a session has been started, the screensaver crashes, and you're left with only the 4.10 default wallpaper and the screen lock dialog on top of it. All consecutive times the screensaver is launched by timeout, it runs properly. - The 4.10 default wallpaper (found here: /usr/share/wallpapers/Elarun/contents/images/) is only avaiable in 2560x1600. It is not scaled down properly to my resolution (1920x1200) when used as the background, making it look very jaggy. You should use a smooth scaling method here. - When the screensaver is launched, the mouse cursor is still visible. It should be hidden. I'm using the kslideshow screensaver, if that is of any importance. This bug is NOT fixed. I am seeing the same behavior in 4.10.1 as reported by Baokai Lei. That is, while the password is no longer required, the screen lock password dialog is still displayed with the screensaver running on top of it and the screenlock dialog should only be displayed when the "password required" option has been checked. When the screensaver is awakened then the password dialog disappears such that the password is not required, however, the dialog should never have been presented in the first place. I am running the kcometen4 screensaver which uses the desktop as the basis for a cubed background. However, because the password dialog is displayed, the 4.10 screenlock default wallpaper is erroneously used for the cubed background instead. I am running KDE 4.10.1 on OpenSUSE 12.3. (In reply to comment #19) > This bug is NOT fixed. > > I am seeing the same behavior in 4.10.1 as reported by Baokai Lei. That > is, while the password is no longer required, the screen lock password > dialog is still displayed with the screensaver running on top of it and the > screenlock dialog should only be displayed when the "password required" > option has been checked. When the screensaver is awakened then the password > dialog disappears such that the password is not required, however, the > dialog should never have been presented in the first place. This is bug #315442 and bug #316296 - the unlock dialog is always displayed and the unlock dialog sits on top of the screensaver. The first problem is unnecessary and confusing and frustrating, but luckily only cosmetic; the second problem you can work around by dismissing the unlock dialog with the Escape key. I had hoped to sort this out for 4.10.2, but that's not looking certain now. Sorry about this. *** Bug 311626 has been marked as a duplicate of this bug. *** (In reply to comment #18) > However, there are still a few issues remaining unchanged in 4.10.1 Sorry, I've had a tab open with this bug for a while, nagging at me to reply to you. Are there any other unreported bugs remaining apart from the ones you mention below? > > - The very first time the screensaver is launched by timeout after a session > has been started, the screensaver crashes, and you're left with only the > 4.10 default wallpaper and the screen lock dialog on top of it. All > consecutive times the screensaver is launched by timeout, it runs properly. > > - The 4.10 default wallpaper (found here: > /usr/share/wallpapers/Elarun/contents/images/) is only avaiable in > 2560x1600. It is not scaled down properly to my resolution (1920x1200) when > used as the background, making it look very jaggy. You should use a smooth > scaling method here. Can you file a bug for these two? > > - When the screensaver is launched, the mouse cursor is still visible. It > should be hidden. Bug #316459 Created attachment 79751 [details]
Patch for smoothing
@Oliver, i can commit this patch for smoothing if i get a green light from you. Or should i use reviewboard?
(In reply to comment #23) > Created attachment 79751 [details] > Patch for smoothing Thanks! > > @Oliver, i can commit this patch for smoothing if i get a green light from > you. Or should i use reviewboard? Use reviewboard: it's good practice, and it will reach people who are better suited to evaluate the patch than me. It looks good to me, but maybe there's some subtlety or better approach I'm not aware of. (In reply to comment #24) > Use reviewboard: it's good practice, and it will reach people who are better > suited to evaluate the patch than me. It looks good to me, but maybe there's > some subtlety or better approach I'm not aware of. Sure, just thought maybe this one is not worth the trouble, as it's a one-liner. Added now: https://git.reviewboard.kde.org/r/110350/ |