On 28.06.2011 13:35, Alexander Surkov wrote:
> Hi, Pete.
>
>> 1) There are some AT, like GOK, that don't care about relations, especially
>> reverse relations which are costly to compute.
>>- Is there a way for the Gecko code to not compute the reverse relations
>> until requested?
> No relatio
de"
> or
> FOCUS | SHOW | HIDE
>
> Not to suggest events are all we care about.
>
> Note:I am also thinking that repeated calls to the API do not unset and
> support features, but are cumulative.
>
> cheers,
> David
>
> Richard Schwerdtfeger wrote:
>
t;>>
>>>> suggestion below.
>>>>
>>>>
>>>> Rich Schwerdtfeger
>>>> CTO Accessibility Software Group
>>>>
>>>> accessibility-ia2-boun...@lists.linuxfoundation.org
>>>> <mailto:accessibility-ia2-boun..
h Schwerdtfeger
>>> CTO Accessibility Software Group
>>>
>>> accessibility-ia2-boun...@lists.linuxfoundation.org
>>> <mailto:accessibility-ia2-boun...@lists.linuxfoundation.org> wrote on
>>> 06/21/2010 01:00:38 PM:
>
feger wrote:
>
>> suggestion below.
>>
>>
>> Rich Schwerdtfeger
>> CTO Accessibility Software Group
>>
>> accessibility-ia2-boun...@lists.linuxfoundation.org wrote on
>> 06/21/2010 01:00:38 PM:
>>
>>
>>> From: James Teh
>>
10 01:00:38 PM:
>
> > From: James Teh
> > To: accessibility-ia2@lists.linuxfoundation.org
> > Date: 06/21/2010 01:13 PM
> > Subject: Re: [Accessibility-ia2] a11y support registry API
> > Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
> >
James Teh wrote:
> On 22/06/2010 4:33 AM, Alexander Surkov wrote:
>
>> In this light reverse API makes more sense - disable what you don't
>> need :)
>>
> I still don't see how this solves the case you are trying to solve. As I
> understand it, current ATs don't really need this feature, b
Hi Jamie,
Sorry I left this thread hanging.
James Teh wrote:
> On 22/06/2010 4:42 AM, David Bolter wrote:
>
This API suggestion is just illustrative. Something like this would
allow applications to provide needed support without wasting performance
by also providing unused suppo
On 22/06/2010 4:33 AM, Alexander Surkov wrote:
> In this light reverse API makes more sense - disable what you don't
> need :)
I still don't see how this solves the case you are trying to solve. As I
understand it, current ATs don't really need this feature, but
applications such as tablet softwa
suggestion below.
Rich Schwerdtfeger
CTO Accessibility Software Group
accessibility-ia2-boun...@lists.linuxfoundation.org wrote on 06/21/2010
01:00:38 PM:
> From: James Teh
> To: accessibility-ia2@lists.linuxfoundation.org
> Date: 06/21/2010 01:13 PM
> Subject: Re: [Accessibili
On 22/06/2010 4:42 AM, David Bolter wrote:
>>> This API suggestion is just illustrative. Something like this would
>>> allow applications to provide needed support without wasting performance
>>> by also providing unused support. Thoughts?
>> This sounds okay. The problem is that in order to preser
In this light reverse API makes more sense - disable what you don't
need :) The problem is to decide what to enable/disable and perhaps
proper engine creation to track what was requested by AT and what
wasn't, and watch lifecycle of AT.
Alex.
On Tue, Jun 22, 2010 at 3:00 AM, James Teh wrote:
> O
On 22/06/2010 2:14 AM, David Bolter wrote:
> IApplicationAccessible
>- setRequestedSupport([in] long supportBitflag, [out] long
> supportedBitflag);
> This API suggestion is just illustrative. Something like this would
> allow applications to provide needed support without wasting performance
>
I'd like to explore the topic of having a programmatic way of requesting
(client) and supporting (server) accessibility features. I'm thinking of
something like:
IApplicationAccessible
- setRequestedSupport([in] long supportBitflag, [out] long
supportedBitflag);
This API suggestion is just i
14 matches
Mail list logo
