The cherry-pick of 923ce7e588
("Fix password field in lock screen not clearing after failed login attempt")
introduced two assignments to properties which don't exist in 5.25 yet. This
causes execution of those blocks to abort early, resulting in a bad state,
like hadPrompt never getting set to true.
BUG: 456639
This bug was introduced by plasma/plasma-workspace!1754.
`lockScreenUi.hadPrompt` was set to `false` in `onFailed()` to avoid
unintentionally clearing the password after the text field had faded
out after 10 seconds and the user pressed a button. Unfortunately this
also caused the password field to not clear right after the failed event.
So instead the statement is moved into the trigger of `fadeoutTimer` which
fixes both issues.
BUG: 455227
FIXED-IN: 5.25.3
(cherry picked from commit 923ce7e588)
Otherwise the user needs to manually tab over to the Unlock button
first, which is annoying. And they may not even think to do it at all.
The `forceActiveFocus()` is because the stack view does not manually pass focus
to the item you push onto it; this needs to be handled manually.
BUG: 454707
(cherry picked from commit 370976d715)
When the lockscreen is in the screensaver mode we want the keyboard key
pressed to wake the screen to go to the password box textfield. This did
work correctly, but a code path also reset it when we get the first
prompt.
In the (currently hypothetical) case of multiple prompts we would want
to clear anything in the prompt.
This uses the existing boolean flag to handle that appropriately.
BUG: 454108
(cherry picked from commit 74a80aaac7)
In the refactor we correctly made it so passwordless users were not
prompted for passwords.
This is in the right direction but the UX was still slightly off as it
meant wiggling the mouse unlocked the screen, not an explicit action.
This patch adds an explicit button that must be pressed if no other
prompts were given during the authentication process.
BUG: 440055
kscreenlocker has a fallback UI loaded if the main QML from the LNF
fails.
As the main code is in a loader the lockscreen /always/ loads even if
the main contents can't be loaded. It also
contributes to a black flicker when loading the lockscreen.
The rationale for the loader was to make the window appear faster. This
hopefully isn't needed now we have the logind integration delaying the
sleep.
If it turns out this is feature desired it would be far more productive
to do this in the greeterapp c++ code. Show an empty QtQuick window and
then set the source on it later. It'd be far faster which would help towards
the original goal and allow us to check the loading.
This patch also removes the opacity fade as there's already an opacity
fade on contents when one moves the mouse when the "screensaver" like
code looks smoother.
BUG: 370676
FIXED-IN: 5.25
This is a stripped down version of customizable demo available at my
invent repo[1]. It is optimized for this particular use-case. Animation
honors right-to-left application layout and "instant animation speed"
preference.
[1]: https://invent.kde.org/ratijas/reject-input-animation/
Because why not; and also because it makes for a nice flow when user
does not have a password set: just press Enter (twice, if focused on a
user list).
It was lost during refactoring some time ago, but the intention was
to give focus to the next item in focus chain assuming that's either a
username or a password field.
This patch is a less flexible but also less messy and more direct way to
achieve practically the same thing. Additionally, explicit Tab focus
reason gives a loginButton a nice visual focus which one would expect
to see instead of no visual changes. It was tempting to directly call
startLogin when password is not required, but that would be surprising
when the signal itself is triggered by the Escape key.
CCBUG: 336368
Amends c067d4985a.
Having `preferredWidth: 1` set on an only item that also stretches with
fillWidth AND without top-to-bottom sizing (fixed size imposed by
parent component) doesn't really make sense. It naturally increased row
layout's implicitWidth by only 1, and that value were used as an input
to the final width expression (bottom-up sizing).
This patch fixes the sizing model to be strictly implicit bottom-up and
explicit top-down, and so the slider no longer collapses.
BUG: 446185
Using "preferred" layout size as a source of truth is more correct than
choosing between minimum and maximum sizes for that same purpose. This
does not technically fix or impact anything per se; just makes the code
slightly better.
having the width entirely dependent on the implicit size of the content
has the unfortunate side effect that a window can become insanely wide.
instead cap the minimum width at a percentage of the screen width.
shrinking beyond that cap then only allows dimension changes in height,
not width. this allows the content items to adjust accordingly (e.g.
labels would be forced to wrap).
NB: height is intentionally uncapped because we need somewhere to put
the "overflow" content
otherwise the dialog may be shrunk beyond the space that the buttonbox
desires resulting in cut off buttons (only when the mainItem is small
enough, naturally)
Currently on the login/logout/lock screens, there is almost no spacing between
the avatar and username, which makes the user' delegate looks too tight.This MR
fixes this issue.
This is a follow-up Merge Request to https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1043 to give Breeze a Desktop Layout file... so that it actually gets identified as having one.
It's just a simple script that adds Breeze's Panel and default Desktop Background engine... which results in the Vanilla KDE Plasma layout and settings you know and love when used.
This merge request does not need the MR it is a follow-up of, however it's redundant without that MR being merged.
<h1>Screenshots</h1>
<h2>Desktop Layout on its own, with appearance settings applied from Graphite Dark's Global Theme</h2>

<h2>Full Breeze (Appearance + Layout)</h2>

Currently, the spacing between the user delegate and the action buttons is is very small compared to the spacing between the action buttons and the OK-Cancel buttons, which makes the logout screen look awkward. This MR fixes this issue.
Let the user configure if the keyboard is enabled with the virtual
keyboard button. Otherwise it feels unpredictable.
This mimicks the UX in plasmashell itself.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2058468
When more than one user is shown on the login screen, username labels
are limited to the width of the avatar so they don't overlap one
another. However they are not allowed to become multi-line strings, so
they can get elided if they are not somewhat short. This was worsened
recently by a change in Plasma 5.24 to increase the size of the
username labels, which shortened the amount of text that can be seen
without eliding.
This commit fixes that problem by allowing constrained username labels
to become multi-line strings with up to 3 lines, and adjusting the
surrounding layout to visually accommodate this.
BUG: 450673
FIXED-IN: 5.24.3
Right now we change the intensity of shadows based on the color scheme's
text color, but with a property called "lightBackground". This indicates
that we wanted to do it based on the background color itself, but did
not or could not, so settled on using the text color as a proxy. However
this is wrong; there is no relationship between the active color
scheme's text color and the color of the background image.
Even if we could or did fix that, it would probably still be wrong,
because using lighter shadows on a genuinely light background would
result in worse contrast and readability, especially if the light
background was very visually busy.
For these reasons, in most other places, we have since settled on the
mantra of "shadows should be black", and this commit makes the lock and
login screens follow that convention as well.
BUG: 449985
FIXED-IN: 5.24.2
Double quoted multi-line strings are custom Qt extension, and thus
should be avoided, as they are problematic for syntax support in
various text editors.
GIT_SILENT