Bug 362189 - a11y: Keyboard (caret) tracking for the Zoom feature
Summary: a11y: Keyboard (caret) tracking for the Zoom feature
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-various (show other bugs)
Version: unspecified
Platform: Other Other
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-24 13:55 UTC by Daniel
Modified: 2020-10-26 08:34 UTC (History)
2 users (show)

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


Attachments
KMag (470.33 KB, image/png)
2018-11-09 12:16 UTC, Vlad Zahorodnii
Details
the patch (9.08 KB, patch)
2019-03-19 10:42 UTC, Vlad Zahorodnii
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2016-04-24 13:55:24 UTC
As a visually impaired user I depend on having a full-screen magnifier running all the time. The fact that KWin has a Zoom feature is thus very exciting.

One feature I would like to suggest is keyboard focus (caret) tracking. It is an important feature for people who need a zoomed-in view all the time. Consider, for example, writing a document. Without caret tracking, the zoomed-in region would stay in-place, and one would have to reach for the mouse a lot to follow the text entry point.

Reproducible: Always
Comment 1 Vlad Zahorodnii 2018-10-21 20:13:50 UTC
@Martin
Is this implementable? I guess we need some sort of protocol for such thing.
Comment 2 Christoph Feck 2018-11-09 12:03:00 UTC
This used to work in KMag, at least the last time I tried it in Qt4 times. I am not sure about the status of accessibility integration in Qt5, but I guess the infrastructure is all there. I suggest to ask in kde-accessibility list.
Comment 4 Vlad Zahorodnii 2018-11-09 12:16:16 UTC
Created attachment 116195 [details]
KMag

I'm not sure whether "Focus" is the correct mode, but the magnified area doesn't follow caret.
Comment 5 Christoph Feck 2018-11-09 13:42:43 UTC
Are you sure KMag is compiled with QtAccessibilityClient dependency?
Comment 6 Christoph Feck 2018-11-09 13:45:30 UTC
I have to admit that I enabled building the Qt5 port of KMag with accessibility support without being able to test if it works. I had hoped someone from the accessibility list commit could confirm.

See https://cgit.kde.org/kmag.git/commit/?id=1f8e4208d72c7f9ce6fa739f477151aab1fadccf
Comment 7 Vlad Zahorodnii 2018-11-09 13:56:17 UTC
(In reply to Christoph Feck from comment #5)
> Are you sure KMag is compiled with QtAccessibilityClient dependency?

I'm using KMag from Arch Linux repos. According to the PKGBUILD [1], it looks like KMag is indeed compiled with QtAccessibilityClient.

[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kmag#n13
Comment 8 Vlad Zahorodnii 2018-11-09 14:28:43 UTC
It looks like zoom effect supported this feature previously. https://phabricator.kde.org/source/kwin/browse/master/effects/zoom/zoom.cpp$220-237
Comment 9 Vlad Zahorodnii 2018-11-09 14:48:04 UTC
Anyway, I'll take a look at libqaccessibilityclient, seems like a good place to start.
Comment 10 Vlad Zahorodnii 2018-11-09 15:56:49 UTC
I created simple demo to test QAccessibleClient:
* https://paste.kde.org/pxmdxtggc
* https://paste.kde.org/p12udv0du

For some reason, it works only with GTK apps. Am I missing something?
Comment 11 Martin Flöser 2018-11-09 16:15:35 UTC
I'm not a huge fan of using the zoom effect for a11y features. I think it is unsuited as it just does pixel upscaling. Ideal would be the application toolkit themselves providing the functionality by e.g. providing the zoom functionality directly in the application or by rendering to a scaled window which gets downscaled by the compositor but allows to provide high quality zoom.

To cut a long story short: I think the time is better invested improving the infrastructure for a11y than to invest into doing weird things in zoom.
Comment 12 Frederik Gladhorn 2018-11-09 18:06:50 UTC
It works for me - for some definition of working. We have one issue - that is when to enable the whole accessibility framework and we don't want to do that without reason since it means sending quite some dbus stuff around.

I just realized that kmag depends on the focus notifications (obviously) but probably doesn't trigger them to be sent.

If you want to test: Run an app with
QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 in the environment and it starts working. I tested for example with dolphin - env QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 dolphin
Comment 13 Frederik Gladhorn 2018-11-09 18:07:57 UTC
And yes, in general people prefer the kwin style of magnification, so combing these features would be very sensible, I think kmag should maybe become a glorified frontend for the kwin effects ideally.
Comment 14 Vlad Zahorodnii 2018-11-26 10:29:03 UTC
(In reply to Martin Flöser from comment #11)
> To cut a long story short: I think the time is better invested improving the
> infrastructure for a11y than to invest into doing weird things in zoom.

Focus tracking in the Zoom effect is currently not working. It would be great either drop it or rebase on libqaccessibilityclient.
Comment 15 Vlad Zahorodnii 2019-03-19 10:42:25 UTC
Created attachment 118907 [details]
the patch

For what it's worth, I made a patch a while ago to port the zoom effect to libqaccessibilityclient.
Comment 16 Vlad Zahorodnii 2020-05-12 06:21:01 UTC
*** Bug 421234 has been marked as a duplicate of this bug. ***
Comment 17 Vlad Zahorodnii 2020-05-18 12:06:18 UTC
I submitted a patch for code review that implements the text caret tracking feature in the zoom effect. Not sure whether it's actually worth it, but I would like to hear some feedback.

https://invent.kde.org/plasma/kwin/-/merge_requests/1
Comment 18 Vlad Zahorodnii 2020-06-01 07:44:54 UTC
Git commit 076b8bc14ce583659ad21898525ec2fbad90a1b5 by Vlad Zahorodnii.
Committed on 01/06/2020 at 07:43.
Pushed by vladz into branch 'master'.

[effects/zoom] Implement text caret tracking

The text caret tracking feature allows to keep the text caret inside the
zoomed area. It can be especially useful when the zoomed area is smaller
than the text editor.

M  +19   -0    effects/zoom/accessibilityintegration.cpp
M  +4    -0    effects/zoom/accessibilityintegration.h
M  +12   -1    effects/zoom/zoom.cpp
M  +2    -0    effects/zoom/zoom.h
M  +2    -0    effects/zoom/zoom.kcfg
M  +1    -0    effects/zoom/zoom_config.cpp
M  +11   -0    effects/zoom/zoom_config.ui

https://invent.kde.org/plasma/kwin/commit/076b8bc14ce583659ad21898525ec2fbad90a1b5
Comment 19 Jos Wijdeven 2020-10-13 23:40:13 UTC
I just updated the kde neon test version to kde plasma 5.20. I enabled the text caret tracking in the zoom effect. But it doesn't seem to work? I tried it in the Kate editor.
Comment 20 Vlad Zahorodnii 2020-10-14 06:15:09 UTC
Are you running kate with QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1?
Comment 21 Jos Wijdeven 2020-10-15 01:01:40 UTC
Hah, that's better. Looks great so far. Few weird things but that might be the VM. I'll try it on bare metal later this week. Thanks!!
Comment 22 Jos Wijdeven 2020-10-17 21:40:45 UTC
I did some testing.

- It works really well with LibreOffice writer.
- When you update or install software, the root password dialog receives focus (fantastic, so you don’t have to search for it)
- Pressing the super key moves the focus to the search box of the menu (great). Only thing here is that the zoomed area doesn’t move all the way to the edge of the desktop so the first part of the search box is outside of the zoomed area.
- It works well with Kate. Except when you move the caret to the end of a line or end of the file some weird jumping of the zoomed area occurs. If you’re typing a line eventually the caret disappears past the right edge of the zoomed area. Moving back one character (left arrow key) makes the area jump back so the caret is inside again but moving the caret forward makes it go outside again. As long as there is at least one character after the caret it works fine.
- Konsole/terminal:  every time you type a character the zoom area jumps to the center of the desktop instead of following the caret.

I don’t know if these are Qt Accessibility things or have to be fixed in the applications themselves?

A little nuisance: when the zoomed area moves to focus the caret it remembers the position of the mouse pointer where the zoomed area was before the focus shift. So when you use/touch the mouse (by accident or on purpose) the zoomed area jumps back to where the mouse pointer was before. You then have to find you spot back again. Maybe there is a way to keep the mouse pointer within the zoomed area (even if it is just on the edge of it, but not on top of the caret)?

Wish list item: right now the zoomed area moves along with every letter typed.  Maybe an extra option is possible that the zoomed area only moves when the caret reaches the edge of the zoomed area, for example with a 10% (or adjustable) margin. That might also prevent the unexpected jumping like in Kate or Konsole?

But so far this is a big help, thank you again.
Comment 23 Vlad Zahorodnii 2020-10-19 16:14:38 UTC
Can you file a separate feature request?
Comment 24 Jos Wijdeven 2020-10-25 18:21:33 UTC
I made a feature request for the wishlist item. Do I need to file separate bug reports for the other issues?
Comment 25 Vlad Zahorodnii 2020-10-26 08:34:25 UTC
yes, please