https://bugs.documentfoundation.org/show_bug.cgi?id=156657
--- Comment #4 from [email protected] --- That's indeed a complicated question, that has other implications as Michael says. I'm happy to review my POV on not exposing everything in Writer if we change how ATs are supposed to use the interfaces and there are reasonable alternatives -- but I'm not even the one that initially reported the issue :) In this specific case, as an AtspiTable has specific interface for querying children, it *might* indeed be OK to not have any children exposed there and require users to go through that interface querying number of rows and columns, and then specific ones (if one wants to iterate, one still can that way). And I admit that there is a performance issue here with tables, even internal LO a11y tests have (and always had) a 500 children iteration limit, likely for those very tables. 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. But before we really know, I'm not sure what we can really do, apart from a hack as was done in that MR -- or is done in internal tests. Or… couldn't the atk-adaptor code do something smart with tables, if there's something to be done? It sounds like a good spot for it. 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. -- You are receiving this mail because: You are the assignee for the bug.
