https://bugs.kde.org/show_bug.cgi?id=458951
Harald Sitter <sit...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Latest Commit|https://invent.kde.org/plas |https://invent.kde.org/plas
|ma/plasma-workspace/-/commi |ma/plasma-workspace/-/commi
|t/7d39865d8ce80380c29806641 |t/ebc17b15d9f8ad99d6b99ab35
|638fd45e52cbf01 |5a47d0bf18a2b07
--- Comment #5 from Harald Sitter <sit...@kde.org> ---
Git commit ebc17b15d9f8ad99d6b99ab355a47d0bf18a2b07 by Harald Sitter.
Committed on 11/10/2023 at 14:02.
Pushed by sitter into branch 'Plasma/5.27'.
lockscreen: handle user switching also on nopassword page
this is a bit awkward but probably the best we can do without major
refactoring. previously we'd miss out on the user switch because that
only got handled on the regular login page, when dealing with a password
less account we'd get carried away by the succeeded signal to the
nopassword page and no user switching page would be on top of the stack
view.
the page flow has been slightly changed to better fit the use case:
- a new function maybeSwitchUser replaces the previous user switcher
- nopasswordunlock now **replaces** the pagestack (which is actually
what it did anyway because it has no back button)
- nopasswordunlock triggers maybeSwitchUser after completion
- regular mainview triggers maybeSwitchUser after completion
that end result is that in both scenarios we get a working switcher page
(cherry picked from commit 7d39865d8ce80380c29806641638fd45e52cbf01)
M +19 -19 lookandfeel/org.kde.breeze/contents/lockscreen/LockScreenUi.qml
M +1 -0
lookandfeel/org.kde.breeze/contents/lockscreen/NoPasswordUnlock.qml
https://invent.kde.org/plasma/plasma-workspace/-/commit/ebc17b15d9f8ad99d6b99ab355a47d0bf18a2b07
--
You are receiving this mail because:
You are watching all bug changes.
