[g-a-devel] Re: OO.o / new a11y bridge ...

[michael meeks <michael meeks novell com>]

Hi Oliver,

	Thanks for your feedback :-)

On Wed, 2005-04-20 at 09:42 +0200, Oliver Braun wrote:
> so far I only took a quick look at your patch. Please see my comments
> below ..

	Great.

> I don't know OAccessibleWrapper unfortunately, but I'll try to take a
> look on this later.

	Great.

> However I have some other feedback and a question for you:
> 
> a) It seems that global focus notification is not working at all -
> unfortunately it is not implemented in OOo yet, so the java bridge
> traverses the full a11v hierarchy of a newly opened frame to add a
> global listener to each object (unless it is below and object having
> MANAGES_DESCENDANT state), listening for FOCUS and CHILD events.

	Ok - right, the code is really rather incomplete :-) as you notice.
It's interesting that we'd need to create AtkObject peers for all those
objects though because of that. Also - from what I can see of calc
(unless there is some deadlock) traversing all the cells causes some
problems [ still debugging that ;-].

	I was very pleased with the writer a11y though - that looked really
nice, clipping the available accessibles almost to the visible page etc.
good stuff.

> I believe we have to do similar things in the at-bridge because I doubt
> we get this implemented in the application code in the near future. This
> may also solve some of the reference counting problems (what is this
> ->acquire loop good for ?).

	Oh - so that was me trying to find the bug I mentioned with OAccessible
Wrapper - as I say, this is not in a pristine state /  perfect or prolly
even usable code [ so much at the same state as most of the a11y
code ;-]. But it's improving, it'd be great to work together on it.

> b) here is the question: since I am not familiar with the glib object
> system, I originally thought it would take one object per a11y role. It
> seems you have solved this problem more dynamically - I am just unable
> to find where ;-).

	Ok; so - the code to do that is fairly simple: atkfactory.cxx is
registered as a factory for all our top-level window widget types. Then
atkwrapper.cxx (ensureTypeFor) dynamically instantiates a new type (if
necessary) for the right combination of interfaces that the accessible
supports - that is the (slightly) funky bit :-) it's all to do with the
rather fun run-time type system that GObject exposes. This way we can
create an object supporting arbitrary (& correct) interfaces in a
(fairly) efficient fashion. I also put some work in to try and keep
complexity down in that method - the table based lookup is quite
nice :-)

	HTH,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot