Mark, gang,
<snip>
Or, imagine we have a large list that is a few items larger than the
screen. Does the child count of the large list only include the objects
on the screen (that would be odd) ?
So - this is basically a variant of the MANAGES_DESCENDANTS thing - if
the list is staggeringly big, we need to have a different behaviour from
if it is say 20 elements: if the latter, I'd advocate exposing them all,
if the former even to expose them to a non-impaired person presents
challenges.
For a very large table list or document; something where many of the
objects in the list may not be in memory, we need a way to navigate the
list or document. One way (That sucks) would be to only create and
expose the objects that are on-screen. So for a very large document the
AT would have to twiddle the 'Value' interface on the scrollbar to read
down the entire document.
An off the cuff interface:
Accessible object implements the "Table" interface it has the
"manages-descendants" state. It also implements the imaginary interface
"TableRange".
The "TableRange" interface has the following method:
Range registerClient ()
The Range interface has the following method:
setRange (minRow, maxRow, minColumn, maxColumn)
The setRange object would do as imagined, create and make accessible all
the objects within a certain range. The purpose of the registerClient
call is that there is one Range object per-client / AT.
The advantages of this interface over reference counting in the infinite
space is that there is no chance of creating a memory leak in the
application via poor reference counting in the AT. There are far fewer
IPC calls to constantly ref and unref objects in the server/application.
Another approach here is to have some call(s) (e.g. Collections
interface) that enables you to get a whole bunch of information based
on some criteria all at once. Then, rather than saying "hey app.,
please bring everything in this manages-descendants thing into memory
for me to play with", you're simply saying "hey app., please give me
this collection of data now".
I'm too far away from implementation to make a strong argument or cast
a significant vote. But I did want to give some voice to the alternate
approach that we'd explore for this issue...
Peter
|
