Thanks for your thoughts! I will gladly expand a bit.
LibreOffice doesn't proactively send a list of all cells, so one
question could be why the screen reader/AT is querying all of the
children (cells) in the first place, rather than only those it's
interested in for some reason, e.g.
* the currently focused cell
* the first and last selected cell to announce something like "cells
A1 to C10 selected"
We absolutely do that, however we're also trying to be ahead of the game
and get the data before the object obtains focus.
* If it's a tool for analysis, one approach might be to just query the
first N children initially, and query more on demand, with N being a
reasonably manageable number.
Not every object will support `Collection` and, there is no other way to
get a range of children other than repeatedly calling
`Accessible::GetChildAtIndex`.
`Accessible` is the only interface that every object support.
Can you expand a bit more on the specific use case you have in mind
where ATs have to query all children?
What any screen-reader/AT would like is to offer best response times to
users by caching objects up-front to minimize IPC round trips between AT
and application.
For `atspi` we would like to offer a cache for any AT to use. A tree
with a subset of data and keep that up-to-date by listening for signals.
You are right LibreOffice does not proactively send a 96G array but it
does offer `GetChildren` on the public bus which will.
It means one can never call `GetChildren` on that object because it
makes no sense. It makes naively building a tree like the example
program [1] does is impossible because LibreOffice Calc wants to return
something that in practical terms no-one can handle.
The `Accesslble` interface is the most used and trusted in general.
Other interfaces may be helpful but implementations do vary.
The discussion in tdf#156657 and the referenced GTK issue [1] have
some considerations on what to potentially do alternatively, with no
definitive approach being outlined yet (e.g. what to do when part of
the selection is off-screen). Input welcome! :-)
In practical sense, if your array of children is huge, please make sure
to not exceed D-Bus message limit of 128MB.
I think a clear concept of how to handle such scenarios in general,
not just for LibreOffice Calc, would be useful, rather than every
application that has a11y objects with a large amount of children
trying to come up with a custom/own solution.
I fully agree, a general rule for reliable behaviour would be
preferable. However, I think most hope the issues will be resolved by
AT-SPI's successor. But introduction and adaptation may take years. In
the mean time, I hope we can agree to do something more sensible.
The `fama11y-tree` branch linked below, `calc-demo`, checks for any
object exposing more than 100000 children and then returns
information on that object and not call `GetChildren`.
As mentioned above, not unconditionally retrieving all children on the
AT side generally sounds reasonable to me.
I disagree. There is no use case for a reply this big, it is not the
actual size of the sheet anyway and it is not a legal reply-message.
Could LibreOffice please limit the reply-message to something reasonably
sized? (Or at least legally sized?) This is currently a bit of a
foot-gun with a public interface.
Thanks in advance!
