vcl/qt5/QtAccessibleEventListener.cxx | 5 -----
1 file changed, 5 deletions(-)
New commits:
commit 4849c98eb44b62324293254c946de41668ecd494
Author: Michael Weghorn <m.wegh...@posteo.de>
AuthorDate: Fri Apr 28 20:44:14 2023 +0300
Commit: Michael Weghorn <m.wegh...@posteo.de>
CommitDate: Fri Apr 28 21:56:50 2023 +0200
qt a11y: Forward changes to active state
Forwarding of a11y state change events had in general
been implemented in
commit 8c3e8af0e60865ec6d38e2117efdb4ed2f10a20c
Author: Michael Weghorn <m.wegh...@posteo.de>
Date: Fri Jun 17 17:29:19 2022 +0200
qt a11y: Forward STATE_CHANGED event as such
, but that commit explicitly did not yet enable forwarding
of changes to the `active` state; quoting from the commit
message:
> For some reason, forwarding changes to state `AccessibleStateType::ACTIVE`
> resulted in Orca becoming unresponsive (stop talking) quite quickly.
> That needs further analysis, so that state change isn't forwarded
> to Qt for now.
I no longer see this problem on Debian testing with Orca 43.1-1,
current LO master and qtbase dev branch as of commit
589c6d066f84833a7c3dda1638037f4b2e91b7aa
plus the pending Qt Gerrit change [1]
("a11y atspi: Implement TableCell methods Get{Column,Row}HeaderCells")
in place. Without the latter qtbase change, I can observe
Orca becoming unresponsive quite quickly when moving around in Calc
after pressing Shift, which may be due to waiting for a timeout
instead of receiving the proper reply to the AT-SPI methods
that that Gerrit change implements. (S.a. QTBUG-113110 [2] for
another scenario using a simple pyatspi script to trigger
what is potentially the same underlying issue.)
Therefore, drop the old workaround.
With this LO and the Qt change in place, Orca announces the
focused and selected cell(s) in Calc with the qt6 VCL
plugin and these steps:
1) start LO Calc with the qt6 VCL plugin
2) press Shift and wait a few seconds
3) move around using the arrow keys
4) select cells using Shift + arrow keys
Ideally, this should also work without step 2, but
apparently that step currently somehow triggers something
relevant (creation of relevant a11y objects and registration
of their listeners?) that doesn't yet happen without step 2.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/473907
[2] https://bugreports.qt.io/browse/QTBUG-113110
Change-Id: Icff8bbe7a6ee233407804c9098166945cdef4315
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151176
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.wegh...@posteo.de>
diff --git a/vcl/qt5/QtAccessibleEventListener.cxx
b/vcl/qt5/QtAccessibleEventListener.cxx
index 59d7dd0a8717..951286a6c1c1 100644
--- a/vcl/qt5/QtAccessibleEventListener.cxx
+++ b/vcl/qt5/QtAccessibleEventListener.cxx
@@ -59,13 +59,8 @@ void QtAccessibleEventListener::HandleStateChangedEvent(
switch (nState)
{
case AccessibleStateType::ACTIVE:
- // ignore for now, since it somehow causes Orca to become
unresponsive quite quickly
- // TODO: analyze further and fix root cause
- /*
aState.active = true;
break;
- */
- return;
case AccessibleStateType::BUSY:
aState.busy = true;
break;
