Re: [g-a-devel] at-spi idea: two registration points of entry



From: Li Yuan <liyuan gnome org>

> So I'm proposing to debate if have sense to add an AT registration.
>>
>> So, it would be something like:
>>
>> a) Target apps register to at-spi2 (as it is done right now on
>>   adaptor_init, bridge.c::664)
>>
>> b) AT apps register to at-spi2 using an alternative (not existint
>>   yet) API.
>>
>> So, when apps register on at-spi2 on a), if there is any AT listening,
>> the bridge will start to add the listeners to their events, and so on,
>> as it is being done now.
>>
>> But if there isn't any AT listening, this registration will not be
>> done, they will be just added to the register. If after some time any
>> AT is registered, at-spi2 will ask to any app registered, to start to
>> add the listeners and so on. In the same way it would be good to add a
>> mechanism to remove the event emission on any app if the count of AT
>> apps listening reaches zero.
>>
> 
> Does this mean all a11y objects are created when the first AT
> starts? I think users may experience a very painful time.

Well, this wouldn't be really so much different to the case of the
current app registration when the atk bridge module is initialized,
and the root is called.

Anyway, yes, if we decided that this would be a idea to check, we
would require to check this hypothetical performance issue on the
implementation phase.

> If not, we may have the performance trouble even atkbridge is not
> sending signals, because gail is still working. Many performance
> troubles are caused by gail, like the treeview one.

Well, yes I already used the treeview as the poster boy of this
proposal. Although I mostly talked about the listener installation, I
was also thinking about avoid the instantiation of the accessible
objects.

With my proposal, without any AT tool, the at-spi register will have
just the list of apps registered, the minimum structure to allow then
call it.

Anyway, as we were talking before about performance tests, it would be
also good to check any performance increase on a "in the middle"
environment, of having the accessible objects but not the event
listeners. After all, I guess that this would be the likely
environment if this case:

 * at-spi2 running, no AT tools
 * execute gcalctool => added to at-spi2, just an item
 * start Orca => added listeners, due Orca interaction accessibility
   objects will be instantiated
 * close Orca => remove the listeners, not sure if we should remove
   the accessible objects.

BR

===
API (apinheiro igalia com)


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