use a state machine to define in a cleaner way
the layout of the lock screen when the keyboard is
open on closed. animate between the state changes with
a slide animation
Depends on D4870
Details
Details
- Reviewers
broulik graesslin - Group Reviewers
Plasma - Commits
- R120:298e58158941: Layout and animations on the on screen keyboard
tested opening the keyboard with different screen locker sizes
to see the text field and the button always stay visible
Diff Detail
Diff Detail
- Repository
- R120 Plasma Workspace
- Branch
- Branch2_backup
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
Honestly I don't think it's a good idea to animate the y position of the main stack. I fear this can result in a completely unusable lock screen as the main elements might get outside the visible area. I had huge problems with the layout of the lockscreen and fiddled quite a bit till I had it working correctly. Compare the problems with the Clock and scaling. I went for overlapping with parts of the UI for a reason as I don't think we have enough screen estate to show both the full UI and the keyboard.
| lookandfeel/contents/lockscreen/LockScreenUi.qml | ||
|---|---|---|
| 71 ↗ | (On Diff #12063) | Why the change to MouseArea? |
| 81 ↗ | (On Diff #12063) | This is not related to the described change. Do we really want to close when clicking outside the keyboard? That could be rather annoying? Anyway I think it should not be bundled with a change saying it's about animations |
| 113 ↗ | (On Diff #12063) | Could you please rebase this to the changes introduces with 097db85e297aba8b4b3f0ddabcddf8a03b5482c0 |
| 221 ↗ | (On Diff #12063) | I'm especially afraid of reintroducing units here with a fixed multiplier. That was exactly the thing causing problems with scaling and the clock. |
Comment Actions
- adress comments
| lookandfeel/contents/lockscreen/LockScreenUi.qml | ||
|---|---|---|
| 71 ↗ | (On Diff #12063) | to dismiss the keyboard by clicking anywhere in an empty area |
| 81 ↗ | (On Diff #12063) | that's how on screen keyboards usually work on pretty much any device. |
| 113 ↗ | (On Diff #12063) | i see that commit puts the clock in a column layout together with just an empty item.. why? looks like some easy cleanup can be done there in adapting to that diff, now hiding the user icon when it goes over the clock, but i think the clock sliding away was actually more correct ui-wise |
| 221 ↗ | (On Diff #12063) | this is not really a functional position: |
| lookandfeel/contents/lockscreen/LockScreenUi.qml | ||
|---|---|---|
| 113 ↗ | (On Diff #12063) | purely ui-wise, i think the correct behavior of the clock (for a future review) should be:
|
| applets/systemtray/systemtray.cpp | ||
|---|---|---|
| 201 | That looks like an unrelated change? | |
| lookandfeel/contents/lockscreen/LockScreenUi.qml | ||
| 291 | note that the previous code did not set the active to false. The idea was that once you activated the virtual keyboard, clicking/touching into the password field also activates if. For that the inputPanel needs to be active. In summary: if you thought I just had forgotten to set it to false, nope, it was intended ;-) | |
| 113 ↗ | (On Diff #12063) | yeah hiding the clock if it overlaps with the user icon would be a good thing. I didn't see an easy way for it, but well me and QML ;-) |
| lookandfeel/contents/lockscreen/LockScreenUi.qml | ||
|---|---|---|
| 113 ↗ | (On Diff #12063) | this way seems to behave as intended, i tried to resize the lockscreen test window to various sizes that may be challenging and seems to behave quite well |
Comment Actions
I fear this change caused regressions. I now don't have the virtual keyboard button on the layout anymore (X11 and Wayland) and on Wayland it's impossible to unlock the screen.
Comment Actions
I just reverted the change locally and that fixed the issue for me. So yes this change unfortunately broke the feature it was supposed to improve. As an idea: maybe it did not incorporate adjustements for 54479d32a96430dd093b4489c6f2a6fe449d2f80.
Comment Actions
so is the virtual keyboard button itself that's invisible? that shouldn't be touched by this patch.
In my master https://phabricator.kde.org/R120:54479d32a96430dd093b4489c6f2a6fe449d2f80 is in (and the button is visible)
Comment Actions
Yes that's one of the problems. The other is that on Wayland the button also doesn't show and nevertheless the keyboard loads directly, but text entering is not possible through virt keyboard nor through physical keyboard.
Comment Actions
i think i found the problem, it was looking for VirtualKeyboard.qml in the wrong path, now it should work
Comment Actions
Thanks for investigating! I can confirm that your commit fixed the issue and as it nicely animates I'm running your latest version ;-)
The wrong path happened through 78d2c9ffbed64c12578e8b94aead3ecad6bf48bb which moved the file to components. And now I also understand the issue on Wayland. Due to the file not being there, kscreenlocker_greet created a standalone virtual keyboard (which was the one I saw) and broke my keyboard input.