Re: [g-a-devel] ATK - Signal indicating new AtkObject creation.

[Mark Doffman <mark doffman codethink co uk>]

Hi Peter,

>>>> 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...

I think I have spotted the problem in both of our solutions. Michael
once mentioned (Can't remember if it was in a conf call, on the phone or
otherwise) that the collections interface can return an infinite
collection.

This is also true of the interface I suggested, although its not
possible to request an infinite space it is possible to suggest a very
large one. Perhaps there needs to be a limit to the amount of objects
that a collections interface can return. There could then be some sort
of "pagination" or iterator interface to move to the next lot of
results. It sounds pretty clunky, but it makes sure that infinite spaces
don't exist.

Thanks

Mark