in the no-password scenario we previously ended up unlocking even
further, causing unexpected auto-unlocks. instead stop the
authenticators machinery and do not try to unlock when already unlocked
CCBUG: 526194
when we deal with no password scenarios we previously entered a not very
well defined unlocked state where the user had to click a button to
actually get rid of the ui. instead encode this as a property and stop
the authenticate machinery when unlocked. notably prevents automatic
unlocks because of the start timer
CCBUG: 526194
this restores previous behavior where the password authentication is not
showing the prompt by default.
this can be enabled by the user with the kscreenlockerrc config
```ini
[UI]
ShowPromptInRegularAuthenticator=true
```
This reverts commit 1e77a2df15.
Some references to the footer were not fixed, breaking the login method:
file:///usr/share/sddm/themes/breeze/Login.qml:65: ReferenceError: footer is not defined
It removed sessionButton which is still needed and referenced, which
also broke login:
file:///usr/share/sddm/themes/breeze/Main.qml:245: ReferenceError: sessionButton is not defined
Had comments noting to keep the implementations in sync between the
lockscreen and sddm versions, not ideal.
Port to a reusable component in plasma-workspace, so they can both use
the same one without concern of keeping them in sync. Also will allow
plasma-login-manager to become the 3rd consumer of this component
without further duplicating code.
If a user has enbled the SlowKeys filter in Accessibility settings, show
this in the lock screen. This is similar to CapsLock being enabled, as
it might be very confusing for a user that forgot about SlowKeys.
Depends On: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6626
I've decided **not** to include the feedback from [https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3660](https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3660) . I could not continue that MR as I failed to push to that branch again (I'm new to git, it's most likely something I've done wrong in my setup, sorry!)
Reason for not including the feedback:
There's currently three potential messages that could be shown: CapsLock Enabled, SlowKeys Enabled, and "root notification" (which I'm not quite sure what they are). Having something along the line of "CapsLock and SlowKeys are enabled" as suggested would potentially become quite complicated, if we also show more message, e.g. "Bounce Keys Enabled". This would lead to quite some possible combinations, blowing up the code and having multiple strings to translate.
I'm open to boldening parts of the string (e.g. **CapsLock** or **SlowKeys** etc.), though the root.notifications are probably not bold ?
| After | Before |
| ------ | ------ |
| {width=375 height=600} | {width=375 height=600} |
@teams/vdg
@teams/usability
Instead of blocking password entry for a fixed time in QML (regardless of the actual timeout pam configures),
we instantly allow sending a new password attempt. If this attempt comes in while we're still in the actual pam timeout,
we queue it to be applied after the timeout ended and disable the password field while it is queued.
The lockscreen has a button for suspend that was written in early days
of QML where we were injectinng context properties and introspecting the
metaobject of the root object.
Since then we have a QML import for suspend and hibernate. We were using
this import already for various features.
This allows for cleanup on the kscreenlocker side.
The lockscreen window showing the greeter should be the window with focus and receiving keyboard input.
This also fixes the case where the greeter window initially featuring the cursor may not be the one that receives keyboard input.
BUG: 512028
This change adds translation contexts to all translatable strings in qml
files that did not have any. Occasionally, the existing translation
contexts are updated for consistency with the newly added ones.
The string themselves are unchanged, save for one instance where the
Accessible strings were somewhat awkward and were a bit streamlined, and
one set of accessible strings in PanelConfiguration that were not
marked as translatable, but are now.
Co-authored-by: Nate Graham <nate@kde.org>
Some low-hanging fruit for linting:
- qualify acces where easily possible
- no custom-parsed PropertyChanges
- drop unused imports
- explicit parameters for signal handlers
- no explicit widths/heights in layouts
- ComponentBehavior: Bound in very simple cases
As of Qt 6.8.2, the fix for QTBUG-127122 causes a positionChanged event
to be emitted when handling QEvent::HoverEnter.
The lockscreen creates a full screen MouseArea on every connected
screen, one of which will cover the current position of the mouse
pointer. This causes QEvent::HoverEnter and then the positionChanged
event to be raised immediately. The mouse position did not change.
Ignore the spurious (first) positionChanged event, show the password UI
as usual in response to further events.
BUG: 499637
Otherwise one appears on every screen, which is awkward. However, forcing it
to be on a particular screen is undesirable, since if that screen is turned off
but not unplugged, it may still be sending a signal to the OS and show up as a
valid screen to show things on.
To alleviate that concern, always show the UI on the screen with
pointer.
Test plan:
- use multiscreen setup and lock screen
- move mouse across screens, verify that only screen with pointer shows controls
- type some password without pressing enter, and repeat previous point
BUG: 409226
CCBUG: 465566
Originally, the clock was always shown on the logout prompt.
However, this was changed, and now the clock is either always there
or never there.
This adds a third option restoring original behavior and allowing
a proper screen saver use case again (e.g. no clock when idle
but the clock when the logout prompt is shown)
BUG: 493422
Part of https://invent.kde.org/plasma/plasma-desktop/-/issues/133.
This replaces the existing option "Clock: Keep visible when
unlocking prompt disappears" with a simple toggle that controls
whether the clock is always or never shown on the lock screen.
From the discussion when the old option was implemented,
(https://phabricator.kde.org/D24893) the use case for the old
option was for users who want an unobstructed view of the lock
screen background. This use case can still be satisfied by the new
option, and perhaps the simplicity of the new option will make it
easier to discover, as the old description in the UI was rather
awkward.
The difference with the new option is that it does not
matter whether the user is currently typing their password. With
the old option, the clock would still be shown when the user moved
the mouse or started typing, which didn't give users a choice to
not see a clock at all.
FEATURE: 472587
FIXED-IN: 6.2.0
This is the lockscreen copied and unmodified from the
look and feel package, move it here in order to remove
potentially dangerous code in lnf themes which should become just configuration repos
