Re: Feature Proposal: Accessibility on by default
On 04/25/2012 02:37 AM, Colin Walters wrote: As the plugin does not do anything when no AT is loaded, OK; that seems to be a relatively recent change (from my admittedly distant perspective). If that's true, and recently the primary cost of a11y has (at least in theory) been deferred to when an AT is loaded, then I'm totally in favor of this change. This change was made the last year. It started with this commit [1], that prevented to add event listeners if no AT is listening. This also includes the creation of the accessible objects or the message forwarding to DBUS. Additionally, one student was making some tests to check if this leads to a real improvement of the performance/memory consumption when accessibility is on but no accessibility technology is listening [2]. This change was made the last year, tested and debugged since then. BR [1] http://git.gnome.org/browse/at-spi2-atk/commit/?id=d0f7dd49eebedc8c3993a116411f5a8320965968 [2] https://mail.gnome.org/archives/gnome-accessibility-devel/2011-October/msg4.html -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
On Wed, 2012-04-25 at 13:12 +0200, Piñeiro wrote: On 04/25/2012 02:37 AM, Colin Walters wrote: As the plugin does not do anything when no AT is loaded, OK; that seems to be a relatively recent change (from my admittedly distant perspective). If that's true, and recently the primary cost of a11y has (at least in theory) been deferred to when an AT is loaded, then I'm totally in favor of this change. This change was made the last year. It started with this commit [1], that prevented to add event listeners if no AT is listening. This also includes the creation of the accessible objects or the message forwarding to DBUS. Additionally, one student was making some tests to check if this leads to a real improvement of the performance/memory consumption when accessibility is on but no accessibility technology is listening [2]. This change was made the last year, tested and debugged since then. I see, very nice work! Thanks for explaining this to me. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
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? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
On Mon, Apr 23, 2012 at 11:49 AM, Piñeiro apinhe...@igalia.com wrote: The change is trivial. It is only required to change the default value of 'toolkit-accessibility' on org.gnome.desktop.interface.gschema.xml.in.in. A one-liner patch. Owner = Alejandro Piñeiro and gsettings-desktop-schemas maintainer (to review the patch) How do I turn this on in 3.2 today? Just so I know what the default experience is going to be. sri Involved parties Accessibility team Current Status === 'toolkit-accessibility' default value is 'false' References == [1] http://blogs.gnome.org/mclasen/2012/03/27/tomorrows-gnome/ [2] http://blogs.igalia.com/apinheiro/2012/03/30/gnome-3-4-finally-orcagnome3/ [3] http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/ [4] http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/ [5] https://mail.gnome.org/archives/gnome-accessibility-devel/2012-April/msg8.html -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
On Tue, 2012-04-24 at 18:33 +0200, Piñeiro wrote: No, but as I mentioned in my original mail, it is not clear how to implement it. I'm not talking about the implementation details of the toggling of the switch, but rather the fallout on the rest of the stack. For example, (and I am working from outdated knowledge here admittedly) it was my understanding that at one point in time, turning on a11y drastically impacted Firefox rendering speed. More that kind of thing - what impact on application performance, on login time, on memory usage, etc.? Granted, this is kind of a tough question to answer without a GNOME equivalent to something like: http://graphs-new.mozilla.org/graph.html#tests=[[83,1,14]]sel=nonedisplayrange=7datatype=running I suppose your proposed plan of try it and see what happens is about the best we can currently do given the state of our current technology, but I was wondering if you had any idea of what the results might be. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
Em Tue, 2012-04-24 às 10:40 -0700, Sriram Ramkrishna escreveu: On Mon, Apr 23, 2012 at 11:49 AM, Piñeiro apinhe...@igalia.com wrote: The change is trivial. It is only required to change the default value of 'toolkit-accessibility' on org.gnome.desktop.interface.gschema.xml.in.in. A one-liner patch. Owner = Alejandro Piñeiro and gsettings-desktop-schemas maintainer (to review the patch) How do I turn this on in 3.2 today? Just so I know what the default experience is going to be. gsettings set org.gnome.desktop.interface toolkit-accessibility 'true' or enable any of the features that require a11y to be turned on (such as the screen reader). Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
Colin Walters walters at verbum.org writes: I'm not talking about the implementation details of the toggling of the switch, but rather the fallout on the rest of the stack. So, here's a simple technical overview of how the a11y stack works for a GTK app (Clutter is similar). Imagine this as layers. 1) GTK 3 compile-time links against (*) 2) ATK may run-time load a plugin that is named 3) atk-bridge compile-time links against 4) libatspi talks over dbus with 5) libatspi compile-time links against 6) Orca You can easily see that there is a very brittle link between step 2 and 3. Toggling the switch to always-on would just mean we always load the plugin. The big advantage in that approach is twofold: A) a11y users don't have to hunt for the on toggle anymore which is one crucial step less in bringing up an accessible desktop. With that, we can also remove a lot of switch-toggling and -querying everywhere in our a11y plumbing. B) We know that the next step of linking everything at compile-time will not cause any fallout once we decide to do it. I suppose your proposed plan of try it and see what happens is about the best we can currently do given the state of our current technology, but I was wondering if you had any idea of what the results might be. As the plugin does not do anything when no AT is loaded, there should be no observable difference. Of course, that's the theory. And while theory and practice are the same in theory, we know they might not be in practice. So the goal is to find the bugs that the people running with a11y on (but no AT running) have not yet discovered and fix them in the next 6 months. Benjamin (*) GTK 2 does this linkage at run-time, too, using the gail plugin. But GTK 3 has integrated gail recently, so this step is already always-on. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
On Wed, 2012-04-25 at 00:31 +, Benjamin Otte wrote: You can easily see that there is a very brittle link between step 2 and 3. Toggling the switch to always-on would just mean we always load the plugin. The big advantage in that approach is twofold: A) a11y users don't have to hunt for the on toggle anymore which is one crucial step less in bringing up an accessible desktop. With that, we can also remove a lot of switch-toggling and -querying everywhere in our a11y plumbing. B) We know that the next step of linking everything at compile-time will not cause any fallout once we decide to do it. That part makes total sense to me (and thanks for the concise explanation). I suppose your proposed plan of try it and see what happens is about the best we can currently do given the state of our current technology, but I was wondering if you had any idea of what the results might be. As the plugin does not do anything when no AT is loaded, OK; that seems to be a relatively recent change (from my admittedly distant perspective). If that's true, and recently the primary cost of a11y has (at least in theory) been deferred to when an AT is loaded, then I'm totally in favor of this change. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feature Proposal: Accessibility on by default
Description === GNOME 3.4 shows improvement in theaccessibility stack:in performance, stability and support of coreapplications like GNOME Shell [1][2]. Although part of this work consisted ofimprovingthe integration of the accessibility support withinthe toolkits (e.g. no more gail, but ATK implemention inGTK+), the accessibility framework isstill relying on plugin loading based on the 'accessibility-toolkit' gsetting value. 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]. Although the hackfest answered some questionsabout how to proceed, there are others which remain. For instance, we want to dropthe atk-bridge loading, but we still need to decide how to accomplish this. And there are other issues that would require our attention first, such aseliminating the need fortoolkits to emit the key events (keysnooping). So after a thread on gnome-accessibility-devel [5] and some chat on IRC, we think that for the moment it would be better to propose a compromise:just switch the default value of 'toolkit-accessibility to true, in other wordsthe accessibility support would beon by default. While a small change in terms of a feature, it would result in more runtime testing (and feedback) for this cycle while we work on the unanswered questions for the next cycle. In the same way, if something goes wrong (like core app X crashing constantly and no solution), it would be easy to revert the changeprior to the end of the cycle. Implementation === The change is trivial. It is only required to change the default value of 'toolkit-accessibility' on org.gnome.desktop.interface.gschema.xml.in.in. A one-liner patch. Owner = Alejandro Piñeiro and gsettings-desktop-schemas maintainer (to review the patch) Involved parties Accessibility team Current Status === 'toolkit-accessibility' default value is 'false' References == [1] http://blogs.gnome.org/mclasen/2012/03/27/tomorrows-gnome/ [2] http://blogs.igalia.com/apinheiro/2012/03/30/gnome-3-4-finally-orcagnome3/ [3] http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/ [4] http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/ [5] https://mail.gnome.org/archives/gnome-accessibility-devel/2012-April/msg8.html -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
