GitLab

The default script already has methods which make it possible for
messages to be spoken. Using these methods will facilitate on-the-fly
language switching.

Also set the interrupt argument to True when using presentObject()
to present updates in state change or the new structural navigation
object.

Chromium is flooding us and we should also get children-changed events.

The default script already has methods which make it possible for
messages to be spoken. Using these methods will facilitate on-the-fly
language switching.

It's only used by the prefs UI and doesn't belong in speech.py.

Some language-related changes uncovered a bug in speech.speak() which
is experienced by users as a regression. For now, just don't trigger
that bug.

This change should not impact the end-user experience. It is a precursor
to implementing support for on-the-fly language switching.

Yet another change that should have no end-user impact at this time.

This is another change that should not impact the end-user experience.
It is a precursor to implementing support for on-the-fly language
switching.

Also add a debugging line so we can identify any apps or toolkits for
which getting text attributes is non-performant.

* Add ability to retrieve attributes for substring. This is needed
  for at least LibreOffice Writer which returns text attributes on
  a per-line basis (even when those attributes haven't changed)
* Retrieve attributes for substring everywhere we can (i.e. also for
  web content)
* Stop caching attributes for web content which was only useful when
  getting all text attributes for an entire element.

If content changes we can have broken or incomplete ranges.

This change should not impact the end-user experience. It is a precursor
to implementing support for on-the-fly language switching.

Also doing call Voice() even when debugging because that will now trigger
language-switching logic we don't want to invoke purely to output the
name of a voice.

Ideally all speech generation would be done by the speech generators.
Unfortunately, there is some legacy code in the scripts which bypasses
this logic. That code needs to include the object when retrieving the
voice from the speech generator so that the to-be-implemented on-the-fly
language switching works with those methods.

The speech generator code was frequently getting the voice prior to
generation and then applying it if there was something to say. Up to
now that was fine because the getting the voice was merely retrieving
it from settings. This will change when on-the-fly language switching
is fully implemented and enabled. Therefore for performance purposes,
we should only get the voice if we definitely have something to say.

This will eventually be used for on-the-fly language switching. No user
experienced changes in Orca's behavior are expected at this time.

Several users provided feedback that "Selection removed" could be
confusing. The best alternative provided by the community was
"Text unselected.

Apologies to translators who already localized this string, and thank
you for such speedy work!

Don't adjust for language for character and word text boundaries.
The results are presumably in a single language.

Fixes #229

Please note: This is a work in progress and there should be no end-user
experienced changes in behavior. It is part of the foundation needed to
eventually make automatic language switching an optional feature.

Should shave some time off of presentation, given all the panels.

Browsers sometimes destroy objects as a result of our grabbing focus
and/or setting the caret in those elements. When this happens, Orca
fails to present the new object correctly because it either no longer
exists at all, or lacks information it once had (like its name) due to
the destruction process having been started.

This commit attempts to work around that problem during structural
navigation by detecting the condition and then looking for a
replacement object at the same accessible path and with the same role.

Note that this work around sometimes fails due to timing and/or browser
bugs. More specifically, if AT-SPI2 has not received a children-changed
event from the parent of the element in question at the time we look for
that replacement, we'll still wind up with the defunct object we had
before. That said, this workaround seems to make things suck a bit less
than doing nothing at all to recover.

* Never treat them as offscreen/hidden labels because doing so can cause
  us to skip over the widget should the label element be offscreen
* Don't keep saying "clickable" when navigating within the label content.