Re: [orca-list] Open/Libre Office: Structural Navigation added for buttons, check_box, combo_box, entry, heading, list box and table.

[Joanmarie Diggs <joanied gnome org>]

> I wish a few users test the patch before it is discarded. It worked
> fine when I tested.

We will not manipulate the GUI (i.e. physically adjust the scrollbar) to
work around a bug in an app or toolkit. That's not just a hack. That's a
hack with potential side effects, including triggering new AT-SPI events
which might cause some other AT (a magnifier, or perhaps something else)
to do something unwanted in response to the event. The fact that you did
not see such an issue while testing Orca without any additional AT's
running doesn't mean the problem does not exist and/or that it will not
exist.

>  It is vital that the patch must not break Orca's performance and
> stability, but testing is the best way to check if it does.

Stability can also be impacted negatively by introducing a bunch of new
code which boils down to a hack. The more code introduced, and the
bigger the hack, the greater the likelihood that this will occur. It is
vital that this does not happen.

>  Soffice is a very popular application. Improving its accessibility

Bingo, improving its accessibility does not mean hacking in Orca. It
means fixing LibreOffice.

>  will benefit a large number of users.

Indeed, users of Orca *and* users of other ATs. Your proposed solution
fails to do that because it fails to really address the problem at its
source.

>  This particular enhancement is also a part of the Orca roadmap.

The roadmap (which I co-authored) says nothing about hacking around this
problem. Achieving that roadmap item can -- and may have to -- include
our fixing the LibreOffice bugs. Or finding someone who can fix them.

>  So I wrote some code to work round the Soffice bugs. 

Not some. Quite a bit. Which, again, manipulates the on-screen GUI
objects.

> I feel this is in line with Orca methodology of having one default
> script to handle the common functions and a special script for each
> nonconforming application.

The intended purpose is not to handle non-conforming applications. It's
to provide different task-specific functionality. What one needs in a
chat app is different from what one needs in a spreadsheet app is
different from what one needs in a calendaring app, and so on.

Yes, we have also used the scripts to deal with non-conforming
applications and toolkits. And we have -- and still are -- paying the
price. Speaking of which:

Last month we had a week-long "ATK/AT-SPI hackfest" at Igalia in Spain.
Stakeholders from many different groups attended. The consensus is to do
what it takes to bring about a much more unified, standardized
implementation of ATK across toolkits and applications rather than
placing this burden on ATs like Orca. It will not happen tomorrow, but I
am confident it will happen. What you have done is a step away from that
much-needed goal; not a step towards it.

--joanie