headers
Piñeiro | 20 Apr 2012 18:15
Favicon

About proposing "accessibility on by default" as feature

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
(Continue reading)

Permalink | Reply |
headers
Peter Korn | 20 Apr 2012 18:41
Picon
Favicon

Re: About proposing "accessibility on by default" as feature

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?

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
(Continue reading)

Permalink | Reply |
headers
Piñeiro | 20 Apr 2012 18:53
Favicon

Re: About proposing "accessibility on by default" as feature

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,
>>
(Continue reading)

Permalink | Reply |
headers
Peter Korn | 20 Apr 2012 19:05
Picon
Favicon

Re: About proposing "accessibility on by default" as feature

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
(Continue reading)

Permalink | Reply |
headers
Trevor Saunders | 29 Apr 2012 07:14
Picon

Re: About proposing "accessibility on by default" as feature

>   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)

I'm not sure I follow this idea of adding calls in atk.  If atk-bridge
stops being a gtk plugin that is dynamically loaded then either people
need to link directly to some new library, libatk needs to link to that
library, or atk needs to include that code in itself.  sI tend to think
the last of these options is the best since tighter integration between
atk and the adaptor should allow a bunch of abstractions to go away.

>   d) We didn't debated how all this changes would affect GTK2 apps.
> Because the fact is that there are apps still not ported.

Well, can't distributions just continue to ship the current
libatk-adaptor for them, and assuming we don't change the dbus protocol
I think everything should just keep working.

We also need to consider how this set up would work with non gtk apps,
and apps that mostly aren't gtk but embed some gtk widgets.

>  * 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.

I'd tend to think this is the right path to minimize risk in the case too
much stuff doesn't work or performance suffers.
(Continue reading)

Permalink | Reply |
headers
Piñeiro | 30 Apr 2012 15:47
Favicon

Re: About proposing "accessibility on by default" as feature

On 04/29/2012 07:14 AM, Trevor Saunders wrote:
>>   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)
> I'm not sure I follow this idea of adding calls in atk.  If atk-bridge
> stops being a gtk plugin that is dynamically loaded then either people
> need to link directly to some new library, libatk needs to link to that
> library, or atk needs to include that code in itself.
"atk needs to include that code in itself" is a better phrasing of my
poorly written "add that call on ATK". Anyway, you listed some of the
options we were talking about on the hackfest:

 * link to a new library (old atk-adaptor plugin becames this new library)
 * atk include that code in itself.
 * <write here your alternative>

And as I said, deciding and  implementing the best one is still pending.

>   sI tend to think
> the last of these options is the best since tighter integration between
> atk and the adaptor should allow a bunch of abstractions to go away.

This was the idea, and one of the reasons Benjamin Otter (IRC:Company)
was interested in this approach. That would also allow to have more
control over it. With a plugin you just load it, and start to work. A
library approach could allow to add some extra methods.

>
>>   d) We didn't debated how all this changes would affect GTK2 apps.
>> Because the fact is that there are apps still not ported.
(Continue reading)

Permalink | Reply |
headers
Trevor Saunders | 30 Apr 2012 16:52
Picon

Re: About proposing "accessibility on by default" as feature

On Mon, Apr 30, 2012 at 03:47:42PM +0200, Piñeiro wrote:
> On 04/29/2012 07:14 AM, Trevor Saunders wrote:
> >>   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)
> > I'm not sure I follow this idea of adding calls in atk.  If atk-bridge
> > stops being a gtk plugin that is dynamically loaded then either people
> > need to link directly to some new library, libatk needs to link to that
> > library, or atk needs to include that code in itself.
> "atk needs to include that code in itself" is a better phrasing of my
> poorly written "add that call on ATK". Anyway, you listed some of the
> options we were talking about on the hackfest:

ok

> >
> >>   d) We didn't debated how all this changes would affect GTK2 apps.
> >> Because the fact is that there are apps still not ported.
> > Well, can't distributions just continue to ship the current
> > libatk-adaptor for them, and assuming we don't change the dbus protocol
> > I think everything should just keep working.
> 
> The issue here is "I think". We need to be sure that we don't break things.

true, someone should test this, but something breaking when nothing
changes seems somewhat unlikely.

Trev

(Continue reading)






Permalink
| Reply
| 



  


  

  












  





    



Gmane