Explaining everybody last changes on a11y (at-spi2-atk)

[Piñeiro <apinheiro igalia com>]

Hi,

as some of you already now, at-spi2-atk, gtk, clutter and other upstream
modules are evolving a lot these days. Anyway, taking into account some
conversation on IRC and mails, it seems that it not all the people are
aware (non-gnome modules, distros, etc). Sorry, sometimes I forgot that
not everybody reads desktop devel list or assist to the weekly
accessibility meeting. So I think that it would be good to explain it to
everybody. This mail can be also used to send more questions or start a
debate/brainstorm.

Background: during the feature proposal period, it was proposed to have
accessibility on by default. The implementation proposed was just
changing the default value of 'toolkit-accessibility' to true [1]. But
on the discussion at the bug opened to do this change [2], some concerns
appeared. For example that this change would also mean activating the
accessibility by default on old modules (like gtk+2), that didn't
include the last improvements on the accessibility implementation. So
the conclusion was that a11y by default was still desirable, but not
with that implementation. It was concluded that it would be better to
make the bridge a library, and change the tricky process of load the
bridge module as a plugin to just link against the library and call a
_init method. Something that was already plannified, but more for the
medium/long term (in my personal case, I had doubts of gtk+ or
gnome-shell accepting a new dependency).

FWIW, I have this process documented on the feature page [3], and I will
update it if something change.

So whats the situation now?:
  * On next releases of at-spi2-atk, the bridge would be also exposed as
a library
  * gtk2 bridge module is already there
  * gtk2 didn't change the way to load the a11y modules
  * gtk3 module removed the call gnome_accessibility_module_init, but it
is planned to be removed [6]
  * gtk3 adds a new dependency, and calls the bridge init method
(gnome-shell does the same)
  * gtk3 blacklist atk-bridge module, in order to not load it (after
all, it is initializing it directly).

All the changes targeted for next releases, and as Mike Gorse recently
said on orca mailing list [5], be careful if you want to use master
versions, as work is in progress.

Although since the beginning the idea was doing the changes affecting
the modules that GNOME controls, while giving time to other modules to
fix their applications properly (Mozilla and LibreOffice were used as
examples here [4]), some people start to raise some concerns. For example:

 a) Current at-spi2-atk from master (so also next releases) is no longer
compatible with GNOME 3.4
 b) Related with a): upgrading gtk3 would require also upgrade
at-spi2-atk, so if you want last changes on gtk3, you would require that.
 c) As a conclusion of a) b): if you want last gtk3 you need to use the
library approach.
 d) Adding at-spi2-atk dependency to gtk added a X dependency so some
builds are broken [7]
 z) Are we forgetting something that could break due this change?

About my personal opinion, about each of the previous items:

About a):

Well, thats really normal IMHO. We are right now on the 3.5 cycle, so it
is normal that as some features are added and used, the version
dependency for other modules increases.

About b) c):

This can be the tricky one. It seems that some apps using gtk3 are
concerned about setting the a11y on by default (so calling the library).
Luke Yelavich mentioned that it would be a problem for Unity. Probably
will be also a concern for Firefox, that are in the process to migrate
to gtk3. Probably this was due problems in the past. But as was said on
the feature proposal thread, a lot of effort was done on the
bridge/at-spi2-core to not send messages (and in general don't affect
the system) unless any Assistive Technology (like Orca) is listening.
Some could suggest that it would be good to maintain the gtk3 module and
provide the possibility to choose between one and the other. But this
sounds really tricky and error-prone. And after all, it is still
possible to maintain the initialization of the accessibility conditionally:
  * NO_AT_BRIDGE is still working [8] (and works for gnome-shell).
  * Unity, Firefox and others have code to decide to load the library or
not. Now they can use the same code to decide if call
atk_bridge_adaptor_init or not
  * In fact that code would be more simple, as calling
atk_bridge_adaptor_init has the equivalent effect

Yes, it is true that apps using atk and gtk will need to make some
changes, but AFAIK, this applies to any gtk improvement/deprecation.

About d)

Well, that just seems a bug that could be solved with some conditional
dependency magic on configure.ac. I wouldn't consider this as a major
problem. Something that probably applies with Firefox and Unity, just in
the case that they don't want to add a unconditional dependency to
at-spi2-atk.

About z)

Well, that is inherent to any new feature, right? 3.5 is unstable (and
as some people says "unstable is unstable"), and we have the bugzilla
for any new eventual bug.

Questions, doubts, comments?

BR

[1]
https://mail.gnome.org/archives/desktop-devel-list/2012-April/msg00107.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=677491
[3]
https://live.gnome.org/ThreePointFive/Features/AccessibilityOnByDefault#preview
[4] https://bugzilla.gnome.org/show_bug.cgi?id=677491#c4
[5] https://mail.gnome.org/archives/orca-list/2012-June/msg00348.html
[6] https://bugzilla.gnome.org/show_bug.cgi?id=678315
[7] https://bugzilla.gnome.org/show_bug.cgi?id=677491#c30
[8] https://bugzilla.gnome.org/show_bug.cgi?id=678125

-- 
Alejandro Piñeiro Iglesias