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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
