API,
Oops! Sorry, no difference. I just missed the compromise option in
your text.
Peter
On 4/20/2012 9:53 AM, Piñeiro wrote:
On 04/20/2012 06:41 PM, Peter Korn wrote:
API,
Accessibility by default has long been a desire. What about an
interim, "prove it" step? Have it turned on by default for the
various 3.5 builds, with the understanding that it will revert
to being off if certain metrics aren't met. BUT... with the
plan that they will be met?
Hi Peter,
Sorry, but I don't understand this. What it is the difference
between that "interim step" that you propose and the second option
that I proposed and I called "compromised option". Quoting myself:
"Finally, comment that probably there is a compromise option, that
is:
<skip>
* For this cycle just propose to change the default value of
accessibility-toolkit. In that case we would still have more
runtime testing, and it would be easy to go back if things are
failing."
BR
Peter
On 4/20/2012 9:15 AM, Piñeiro wrote:
Hi,
some context: on last ATK/AT-SPI2 accessibility hackfest [1] one of the
ideas that came again to the table was proposing to set accessibility
support on by default. That work would include having the accessibility
nits running all the time, without a accessibility-toolkit setting
switch, and also stop to having the accessibility code loaded as
plugins. At this moment the only remaining plugin is the atk-bridge, so
the idea is having the same functionality as a library call. Something
like a atk_bridge_init (..) call (equivalent to gtk_init).
On our last accessibility meeting we were talking about proposing this
as a new 3.6 feature, as seems a good way to start the discussion with
the community. From that meeting:
Apr 19 16:10:13 <API> #action Piñeiro after some researching, will
bring the having accessibility by default 3.6 to the accessibility list
Apr 19 16:10:32 <API> #action Piñeiro after some debate we could
propose it as feature
So after that research I'm here to talk about this (output of that
research at the appendix of this mail).
So lets see the current situation:
* Accessibility performance and stability has been improving during the
last two releases.
* GNOME-Shell (for user POV, GNOME) accessibility has improved with the
last release.
* But there are still several core applications (ie: evolution) without
a proper accessibility support (also crash-prone)
* Now it is possible to enable accessibility on runtime, without
requiring the uncomfortable logout
* Most of the bus traffic is not sent unless one AT is listening
As we mentioned on the meeting, having the accessibility running would
provide more testing on the accessibility framework, both on runtime and
on compiling time (as at-spi2-[core/atk] will became a compiling
dependency).
The problems I see are:
a) About having accessibility enabled all the time: right now
activating the accessibility on runtime works, so some people would be
against adding an inherent risk
b) About stop to using plugins: some people will not like adding a new
dependency to their projects (this could be irrelevant if the final
solution is add that call on ATK, as randomly suggested on the hackfest)
c) Although we agree that we want to stop to load the bridge as a
plugin, we are still not sure about how and where implement it.
d) We didn't debated how all this changes would affect GTK2 apps.
Because the fact is that there are apps still not ported.
e) My inner pessimist thinks that getting to a conclusion, implement
it, integrate it and test it are too much, and it would be difficult to
have all ready for 3.6
Finally, comment that probably there is a compromise option, that is:
* Keep working on c), as seems the way to go. Probably with unstable
branches of atk, at-spi, gtk and clutter
* For this cycle just propose to change the default value of
accessibility-toolkit. In that case we would still have more runtime
testing, and it would be easy to go back if things are failing. If
things are not failing, it would be a good way to minimize a) if we
propose to remove the gsetting switch.
With that compromised option, for this cycle we would just propose to
change the default value of accessibility-toolkit, while working on the
other stuff.
So, ideas, thoughts?
***
Appendix (somewhat offtopic or this mail main topic)
That research that I wanted to do was check why the following was working:
1. accessibility-toolkit is disabled
2. gnome-shell is running
3. Via Universal-Settings you activate "Screen reader", this sets
accessibility-toolkit as enabled
4. Orca interacts properly with gnome-shell
The "classical GNOME accessibility" wisdom tell us that 4 is not
possible, and you need a logout. Also take into account that gnome-shell
has a custom code that loads that module if that gsetting is enabled.
With GTK3 this was not required anymore thanks to the gsettings-daemon
magic, and the at-spi2-atk.desktop file, that informs that when
accessibility-toolkit became enabled, it should load the bridge.
So, how gnome-shell does that? Well ... thanks to gsettings-daemon, as
gnome-shell also calls gtk_init, so it is also a GTK app. In fact, if
you remove that custom loading-code, in some situations it is still
working (note "some situations", so we can't remove that code yet). As
you can guess, those "some situations" are exactly the situations we
were expecting this all to be failing. In the same way, that
"NO-AT-BRIDGE" "NO-GAIL" code is still required to ensure that AtkUtil
implementation of GTK is not loaded. Yes, all this seems tricky and
fragile, and for sure requires some cleaning, but for now it is working.
BR
[1]
http://blogs.igalia.com/apinheiro/2012/01/24/atkat-spi2-hackfest-2012-days-2345/
--
Peter Korn | Accessibility Principal
Phone: +1 650 5069522
500 Oracle Parkway | Redwood City, CA 94065
 Oracle is committed
to developing practices and products that help protect the
environment
--
Alejandro Piñeiro Iglesias
--
Peter Korn | Accessibility Principal
Phone: +1 650 5069522
500 Oracle Parkway | Redwood City, CA 94065
Oracle is committed to developing practices and
products that help protect the environment
|
