[Kde-accessibility] [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...

[Bill Haneman]

Michael Meeks wrote:
> ...
>
> 	Sure: it's mostly a matter of socialisation:
>
> 	* first we ask the ATs what they actually use "the whole DOM"
> 	  for:
> 		+ eg. "count number of headings in a document"
> 		+ "skip to next heading quickly"
>
> 	* Then we create a new 'Browse' interface that can be used for
> 	  these things:
> 		+ this interface would broadly behave like a set of 
> 		  keybindings: skip to next heading eg. which would
> 		  substantially alter the view / invalidate a load of 
> 		  previously 'live' peers - but get what you want.
> 		+ Other ideas might be a separate 'View' concept that
> 		  would be an 'off-screen' view of headings eg.
>   
This is one of the main use cases that the 'Collection' interface was 
designed for.   Collection is an AT-SPI interface currently under 
development, not sure what the calendar for it looks like at the moment.

See 
http://www.gnome.org/~billh/at-spi-new-idl/html/html/classAccessibility_1_1Collection.html

The idea was to allow the application to perform the search logic rather 
then either performing the search via IPC or pulling the whole DOM/tree 
over and searching in the client.

This also helps with the "infinite space" problem, insofar as Collection 
allows limiting the
number of responses (along with response ordering),  and also allows 
returning only the number of "hits", both of which can be used by an 
intelligent client to avoid "infinity" traps.
> 	This is IMHO the only sane way to do this anyway; eg. exposing infinite
> spaces: eg. "all time", or "1 million x 16k spreadsheet cells" via the
> current interface is somewhat tortured anyway.
>   
Also, regarding a recent StateSet discussion, the interface was 
conceived with the notion that clients would reuse StateSet objects, 
i.e. that they would be somewhat persistent in the client (explicit 
refcount again, I know).  This would reduce the ref/unref pair to a 
"once per logic combination" overhead.

StateSet was also designed to reduce load on the server - i.e. only the 
pieces of state which are to be used must be created.  Some bits of 
state are cheap and easy for the server to determine, but perhaps not 
all.  Also the StateSet allows, if memory serves me correctly, for more 
complex logic that just a bunch of booleans. 

I'm sure I'll have more comments about the current discussion after the 
holidays.

Best regards and Merry Christmas/Happy Holidays,

Bill
>   
>> Actually I'm not really convinced that exposing the DOM necessarily
>> implies reference counting, we still have the base lifecycle management
>> of the 'page' being 'visible' surely ?
>>     
>
> 	Nah; that's the problem - exposing the DOM means exposing the whole
> document model, including tons of things that are off-screen. ie. it's
> easy to say "give me all headings" - ~none of which are visible, or to
> iterate over the entire document - a paragraph at a time, unreffing them
> - most of which are not visible. [ you see the issue I hope ].
>
>   
>>  Its simply a matter of how
>> efficient exposing the dom is, and a dbus-basing interface would imply
>> that we don't need real objects representing the members of the DOM,
>> gecko could just talk dbus directly. (Obviously this is more work than
>> just being able to plug into the current ATK stuff though)
>>     
>
> 	Yep, that busts ATK and it's semantics quite badly. Currently eg. you
> get object lifecycle warnings (AFAIR) mostly only for live peers: ie. we
> don't go creating them to tell people we're freeing them ;-)
>
> 	The way OO.o does this (FWIW) is to only maintain peers for visible (or
> nearly-visible) pieces of the document - if you play with a recent
> version it uses ATK natively: I'd like to move all apps to doing that -
> to remove these problems, though of course we need to expose whatever
> the ATs want & need to make this work nicely.
>
> 	HTH,
>
> 		Michael.
>
>