No longer use a "Accessibility"/"EnableATToolSupport"
VCL setting to control/report whether support for
assistive technology is (or should be) enabled,
which was primarily used on Windows.
As described in previous commit
Change-Id: I32624b830d39d08510e4731edd06fd7a77642c50
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Mon Oct 28 21:12:48 2024 +0100
win a11y: Drop "Enable AT Tool support" from options UI
, that setting got automatically enabled when an assistive
technology was active on Windows, and never got reset to
"false" automatically, so AT support would be enabled
next time LO starts as well.
Instead of persisting this via a setting, enable the
Windows a11y bridge if and when a WM_GETOBJECT message
is received only, see `ImplHandleGetObject` (where this
was already done earlier) and no longer alternatively
start the a11y bridge in Desktop::Main when the mentioned
setting is enabled.
Drop MiscSettings::SetEnableATToolSupport altogether.
Adjust MiscSettings::GetEnableATToolSupport to no longer
read a setting, but return `true` if the AT bridge
has been activated (or a SAL_ACCESSIBILITY_ENABLED
environment variable is set, as was already checked
before).
This already returns `true` when called from
MenuBarManager::FillMenuManager when starting
LO while the NVDA screen reader is running.
With this in place, the a11y bridge on Windows
should now become active whenever an AT requests
information (by sending a WM_GETOBJECT message),
but not otherwise, and restarting LO will result
in the a11y bridge no longer being active unless
AT requests information again.
Change-Id: I42f0059cecd43205690d958a875d3c17ff9a197b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175795
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
c5b6e3ac56