For accessibility reasons we want to make sure that the QQuickWindow
thinks the focus is on the correct item. This will allow screen readers
to read which window is current in the window switcher.
Details
Running with accessibility inspection tools I see that the
right item has the focus with this change.
Diff Detail
- Repository
- R120 Plasma Workspace
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 4557 Build 4575: arc lint + arc unit
lookandfeel/contents/windowswitcher/WindowSwitcher.qml | ||
---|---|---|
47 | Doesn't the focus: true imply that already? |
lookandfeel/contents/windowswitcher/WindowSwitcher.qml | ||
---|---|---|
47 | It would if the window did end up having the focus in some form. As far as I can tell it doesn't ever get the focus (since kwin decided that it shouldn't). Doing this makes qt quick focus handling work while leaving the real window focus alone. |
What's with alternative window switchers? They all would need this force activation as well.
I would very much like to see a more robust and generic solution to the problem. Best would be imo to look again into activating the tabbox window on KWin level directly. That it doesn't do this is a semantic error.
lookandfeel/contents/windowswitcher/WindowSwitcher.qml | ||
---|---|---|
47 | Solutions like this always carry the risk of regression. What if in a future Qt release the window focus gets checked before focus gets force activated? |
Removed Qt.X11BypassWindowManagerHint which makes everything work
Thanks for encouraging this. If anyone has any ideas why the window manager hint was set, I'd be interested to learn.
"Everything" meaning activeFocus within the window or including orca focus awareness?
It looks like I need either forceActiveFocus or to remove the window manager bypass hint. Or find some other way to get the focus on the window...
Changed it to be more pleasant by using client as role and set the focus on the top level, so that the geometry is also more sensible.