Re: Feature Proposal: Accessibility on by default



On 04/24/2012 05:13 PM, Colin Walters wrote:
> On Mon, 2012-04-23 at 20:49 +0200, Piñeiro wrote:
>
>> During the last ATK/AT-SPI2 hackfest, wediscussed that the next step
>> would go a step further:  'accessibility-toolkit' would disappear,
>> plugins would also disappear, and the accessibility support would be a
>> integral part of GNOME toolkits and applications. As a result,
>> accessibility support would receive more attention, both on runtime and
>> on compile time, and more feedback would be received [3].
> Do you have any list of known regressions from doing this?

No, but as I mentioned in my original mail, it is not clear how to
implement it. For example, if we stop to load the bridge as a module, we
could have something like atk_bridge_init (equivalent to gtk_init or
clutter_init). But what library will have that call?. Some options:
  * Create a library based on current atk-bridge module. That would mean
a new accessibility related dependency on some modules.
  * Move that functionality to atk itself (so adding a at-spi2-core
dependency there)
  * The final decision for the previous bullet items are affected by the
fact that we would like to stop to have two accessibility APIs (one for
the client (ATs) libatspi, and other for the server (applications) ATK)
if possible [1]
  * Benjamin mentioned that it would be good if that library provided
some kind of extra features, to get some kind of control of the bus
emission from the toolkit implementation if required
  * etc

As described on my proposal, there are still too many decisions and too
much work to do. Proposing all this as a feature doesn't seems feasible
for this cycle.

This is the reason we proposed a compromise solution.

BR

[1] https://bugzilla.gnome.org/show_bug.cgi?id=652777

-- 
Alejandro Piñeiro Iglesias



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