Re: [g-a-devel]Patch for at-poke

[Bill Haneman <Bill Haneman sun com>]

Michael said:
...
>	Of course - I hope we know now that the API should have been:
>
>	sequence<Accessible> getVisibleChildren ();
>
>	and we shouldn't have tried to design something that would return
>object references to potentially billions of invisible objects. [ this
>is a total waste of time / travesty of design ].

Interestingly it was partly on the advice of AT vendors that we 
opted to return "all" accessible children and not just those that 
are 'visible'.  Also, not every accessible object has a graphical 
element, some UI elements aren't GUI elements but are some other kind 
of control.

ATs should not in general enumerate children (i.e. walk the tree), at least 
not frequently, so I think this is not quite the enormous problem you suggest.  
That said, adding API for getting visible children might be a good idea, if 
we can reliably solve the issue of computing visibility for objects in scrolling 
viewports, etc.

- Bill

>	The current round-tripping approach, is (as I hope is plain now) really
>bad news for race conditions, performance - and all this just to give
>the 1 (non) feature of being able to access objects you're not actually
>interested in.[1]
>
>	;-)
>
>		Michael.
>
>[1] - which amusingly have to be culled in real at's by yet more
>round-trips I guess.
>-- 
> mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot
>
>_______________________________________________
>Gnome-accessibility-devel mailing list
>Gnome-accessibility-devel gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland