https://bugs.documentfoundation.org/show_bug.cgi?id=156657
--- Comment #5 from Michael Weghorn <[email protected]> --- Thanks for your replies! (In reply to Joanmarie Diggs from comment #3) > Normally all objects that might be of interest should indeed be in the > accessibility tree. The fact that they are not in the case of, say, Writer, > is why Orca users (and NVDA users I believe) cannot use Structural/Quick-Key > navigation in documents. Please expose more -- not less -- in the > accessibility tree. That's what I understood as being the reasonable way to go before being uncertain when seeing this bug report, thanks for confirming. > I honestly don't know if thousands of paragraphs would grind the system to a > halt or not. The change in Atspi sets the maximum number of children in > descendable objects to 65536. I'll test later. If that makes the problem go > away, my guess is thousands of paragraphs would still be ok. To be honest, from the LO side I'd actually be surprised if having LO process thousands of paragraphs wouldn't cause performance issues. > AtspiCollection is fast. I'm curious: Is that true for any application or only if apps/frameworks support AtspiCollection to actually optimize retrieving objects via that interface? Or does using AtspiCollection bring a performance benefit even otherwise, e.g. because libatspi or some other "lower layer" does something smarter other than falling back to just iterating over all children/the whole tree? > The Calc table has 2,147,483,647 children. That's a bit more than > "thousands". In reality, it has even more children now with 16k column support, but that's the maximum that the 32-bit integers in the AT-SPI API are able to report, which is also why just using the child index to retrieve e.g. a cell in the last row wouldn't work and the TableCell interface is used instead (s. tdf#150683). > Regarding the status bar test. To be clear, that was just to force the bug > to be reproducible. The changes I'm making to Orca will be to use > AtspiCollection **any time the task is to find one or more descendants**. > And Orca does that often enough -- including for its Flat Review feature > which is notoriously non-performant. AtspiCollection will fix that. And Flat > Review's purpose is to present on-screen objects, so documents are relevant. I see. (In reply to cwendling from comment #4) > However I'm with Michael here: we'd need to settle one what apps/toolkits > are expected to report for what, because if we're having special cases that > are more complex than implementing the APIs (like reporting children here), > we need to have a spec for everyone to agree on what they should do or can > expect. > > It's a big well known issue currently that we lack clear documentation and > guidance on how those APIs are supposed to be implemented and used, and I > believe Joanie and… Matt maybe? have plans on writing some of that -- which > is awesome. Yes, having clear documentation on what apps/toolkits are supposed to do would really be great. It might be somewhat easy to *somehow* adapt LO to not hang on the attached script, but anything I can come up with so far would feel like a terrible hack that somewhat breaks the semantic model (and affects other interfaces like the Table interface) of how I currently understand tables to be modeled in LO... > (...) Or maybe we possibly could > improve the situation implementing AtspiCollection in LO? But ATM it's not > really an option as ATK doesn't seem to have it, and the GTK3 VCL uses it. There's currently tdf#35654 for the lack of AtspiCollection support in Writer docs. @Joanmarie: reading your tdf#35654 comment 10, I'm wondering what would have to be done on LO side to support that? -- You are receiving this mail because: You are the assignee for the bug.
