Re: [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...

Michael Meeks wrote:

	Sure: it's mostly a matter of socialisation:

	* first we ask the ATs what they actually use "the whole DOM"
		+ 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.


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,

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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]