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