Re: [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...
- From: Bill Haneman <gnome billhaneman ie>
- To: michael meeks novell com
- Cc: gnome-accessibility-devel <gnome-accessibility-devel gnome org>, accessibility-atspi-linux-foundation <accessibility-atspi lists linux-foundation org>, Mark Doffman <mark doffman codethink co uk>, kde-accessibility <kde-accessibility kde org>, accessibility-linux-foundation <accessibility lists linux-foundation org>, Li Yuan <Li Yuan Sun COM>
- Subject: Re: [g-a-devel] [Accessibility] a11y / D-Bus / lifecycle ...
- Date: Sun, 23 Dec 2007 19:05:29 +0000
Michael Meeks wrote:
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.
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
+ 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.
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.
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.
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.
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
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.
] [Thread Prev