I'm afraid your patch does not apply for me:

$ arc patch D21192
 INFO  Base commit is not in local repository; trying to fetch.
Created and checked out branch arcpatch-D21192.
Checking patch lookandfeel/contents/lockscreen/MainBlock.qml...
error: while searching for:
        focus: true
        echoMode: TextInput.Password
        inputMethodHints: Qt.ImhHiddenText | Qt.ImhSensitiveData | Qt.ImhNoAutoUppercase | Qt.ImhNoPredictiveText
        enabled: !authenticator.graceLocked
        revealPasswordButtonShown: true

        onAccepted: {

error: patch failed: lookandfeel/contents/lockscreen/MainBlock.qml:59
error: while searching for:
    PlasmaComponents.Button {
        id: loginButton
        Layout.fillWidth: true

        text: i18nd("plasma_lookandfeel_org.kde.lookandfeel", "Unlock")
        onClicked: startLogin()

error: patch failed: lookandfeel/contents/lockscreen/MainBlock.qml:93
Checking patch lookandfeel/contents/lockscreen/LockScreenUi.qml...
Hunk #1 succeeded at 40 (offset 4 lines).
Applying patch lookandfeel/contents/lockscreen/MainBlock.qml with 2 rejects...
Rejected hunk #1.
Rejected hunk #2.
Applied patch lookandfeel/contents/lockscreen/LockScreenUi.qml cleanly.

 Patch Failed! 
Usage Exception: Unable to apply patch!

Did you work against git master, or the version that was on your machine? If the latter, you need to work on git master if you're going to submit a patch that will be applied against git master. :)

Thanks! In testing this out, I find that the impact is quite muted since the text field de-focuses itself after you press the return key. So in practice, if you realize that you typed the wrong password, you can't actually start typing immediately because the text field has lost its focus. I think it would keep to keep its focus while the button is disabled in order for this to work like you're intending.

That's correct. 2 points however:

• I think the detection of a wrong password is very fast and at least on my system I immediately get the highlighted focus. When you say muted, is it slow to do this for you?
• We probably can't do the immediate focus because of the bug mentioned on line 49: https://cgit.kde.org/plasma-workspace.git/tree/lookandfeel/contents/lockscreen/MainBlock.qml#n47. It seems if the password was entered correctly and the textbox has focus, the app would crash.

Cool! Thank you for the pointers to the correct place. It was much easier than I thought once I looked at the code.

Yeah, isn't QML just so nice to work with!?

This one was easy enough. I definitely liked the fact that I could edit the qml files directly and test it live without going through a compilation step. I especially enjoyed it after I managed to crash the lock screen with a typo but was able to fix the stuck lock screen by editing the qml file in a tty and killing the lockscreen process to make it reload. On the other hand, a compilation step here would've prevented this in the first place!

The rest of the code is still arcane magic to me though :)

I don't want SDDM and the lockscreen to have subtly different behaviours.

If one is changing, the other should too.

See similar files in sddm-theme

Oh, duh, right. Yes, please change the login screen version too.

Hi David!

Hmm, it seems the behavior is already different. I don't use sddm, but I tried it just now and found that the input field is already *not* disabled, plus, the notification that the login failed comes after the timeout. Looking at the qml code, the "Login Failed" message is displayed on the onLoginFailed signal, so it'd mean that this signal is delivered only after the grace period, which is different from the lock screen where (it appears) that the onFailed is delivered as soon as the password check fails.

I don't know where the onLoginFailed signal is coming from in sddm (or where the authenticator in lockscreen is defined for that matter). This will need help with a deeper investigation from someone who knows the components well.

Friendly ping! Since the behaviour is already different, can we merge this one and work on the SDDM part in a later PR?

I agree with David, when doing these sorts of changes it's imperative they're instantly implemented in all relevant places. I checked SDDM (with our theme) and the password field is disabled when in the timeout period so we need to fix that.

Maybe this commit can help as a starting point for editing the SDDM theme: e9c72a0420c1

I took another look. As I already mentioned, there seems to be a difference between how onLoginFailed signals work in both.
In the lock screen:

• the onLoginFailed signal is delivered as soon as the password is detected to be incorrec. I use this signal to selectAll() the password text so the user can start editing.
• The grace timeout is a separate signal onGraceLockedChanged, which is used to clear the "Login failed" message.

To summarize, the flow is: (enter password) --> (loginFailed) --[authenticator timeout expires]--> (graceLockedChanged).

On the other hand, in sddm:

• the onLoginFailed signal is delivered only after grace timeout has expired.
• the "Login failed" message is cleared with a qml timer.

the flow is: (enter password) --[authenticator timeout expires]--> (loginFailed) --> (notificationResetTimer).
The behaviour of sddm can only be made the same as the lock screen if the loginFailed signal is delivered independent of the authenticator timeout.

If someone can tell me how the onLoginFailed signals are generated, I can take a look to see if there is a difference in the backend timers. I'm guessing there is some C++ code handling this?

I only worked on the visuals of the theme so I'm not 100% sure either, but there is extra dummy data that might be worth looking it, sddm.qml in particular: https://github.com/KDE/plasma-workspace/tree/master/sddm-theme/dummydata

@siddharthasahu would you like to continue working on this?