Bug 466968 - List of keyboard layouts in SDDM theme is hard to scroll with a pointing device and impossible to scroll with a touchscreen
Summary: List of keyboard layouts in SDDM theme is hard to scroll with a pointing devi...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Theme - Breeze (show other bugs)
Version: 5.27.2
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: accessibility, usability
Depends on:
Blocks:
 
Reported: 2023-03-06 20:10 UTC by Marc Deop
Modified: 2023-03-11 04:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.104
Sentry Crash Report:


Attachments
layouts_list (1.46 MB, image/jpeg)
2023-03-07 19:39 UTC, Marc Deop
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Deop 2023-03-06 20:10:06 UTC
SDDM running with: CompositorCommand=kwin_wayland --no-global-shortcuts --no-lockscreen --inputmethod maliit-keyboard --locale1

Touching on the "Keyboard Layout" button on the lower left part of the screen shows the list of possible layouts but it's not easily scrolable with the touchscreen.

Scrolling though the list is  only possible after making appear the "scrolling sidebar" (is that how it's called?). However, it takes me many attempts to make it appear and then to **select* it.

STEPS TO REPRODUCE
1. Touch the "Keyboard Layout" selector 
2. Try to scroll through the list via the touchscreen


OBSERVED RESULT
There doesn't seem to be any obvious way to scroll the list (no button, no indicator, no two fingers, no three fingers...)

EXPECTED RESULT
To be able to scroll through the list. Ideally just with the finger/s or alternatively with a button to go up/down the list

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 5.27.2
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Comment 1 Nate Graham 2023-03-07 19:35:19 UTC
Hmm, it shouldn't need to be scrolled in the first place. Can you attach a screenshot of that it looks like when it's in this state?
Comment 2 Marc Deop 2023-03-07 19:39:22 UTC
Created attachment 157090 [details]
layouts_list
Comment 3 Nate Graham 2023-03-07 19:43:37 UTC
Got it. Can confirm. It's even annoying with a pointing device.
Comment 4 Nate Graham 2023-03-08 03:57:51 UTC
This menu is provided by PlasmaComponents3.Menu, which appears to not respond properly to either a scroll action or a touchscreen flick/swipe, at least in this context. The code largely looks set up for it. Maybe there's a weird bug in it...
Comment 5 Nate Graham 2023-03-08 04:11:50 UTC
I see the problem:

interactive: ApplicationWindow.window ? contentHeight > ApplicationWindow.window.height : false

In the SDDM login screen, ApplicationWindow.window is null, so we fall back to false.
Comment 6 Bug Janitor Service 2023-03-08 04:17:02 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/754
Comment 7 Nate Graham 2023-03-08 17:27:47 UTC
Git commit e4830f160bcec9e30f6181c75dead7817020d874 by Nate Graham.
Committed on 08/03/2023 at 17:24.
Pushed by ngraham into branch 'master'.

PC3 menu: make interactive condition more robust

If the menu has a content height that exceeds the available height, but
ApplicationWindow.window isn't set--for example because we're in the
SDDM login screen where there is no application window--then we'll hit
the fallback condition and be non-interactive, which makes the menu
terribly difficult to scroll with a pointing device and impossible to
scroll with a touchscreen.

To fix this, consult Window.window rather than ApplicationWindow.window.
This is what other styles do.
FIXED-IN: 5.105

M  +2    -1    src/declarativeimports/plasmacomponents3/Menu.qml

https://invent.kde.org/frameworks/plasma-framework/commit/e4830f160bcec9e30f6181c75dead7817020d874
Comment 8 Nate Graham 2023-03-08 17:35:01 UTC
Git commit a8f127192a94e1effbd2f2366f3bfd77f53333e8 by Nate Graham.
Committed on 08/03/2023 at 17:31.
Pushed by ngraham into branch 'kf5'.

PC3 menu: make interactive condition more robust

If the menu has a content height that exceeds the available height, but
ApplicationWindow.window isn't set--for example because we're in the
SDDM login screen where there is no application window--then we'll hit
the fallback condition and be non-interactive, which makes the menu
terribly difficult to scroll with a pointing device and impossible to
scroll with a touchscreen.

To fix this, consult Window.window rather than ApplicationWindow.window.
This is what other styles do.
FIXED-IN: 5.105


(cherry picked from commit e4830f160bcec9e30f6181c75dead7817020d874)

M  +2    -1    src/declarativeimports/plasmacomponents3/Menu.qml

https://invent.kde.org/frameworks/plasma-framework/commit/a8f127192a94e1effbd2f2366f3bfd77f53333e8