headers
Matthias Clasen | 5 Dec 2009 20:51
Picon

at-spi2 first impressions

Hey,

after months of ignoring the coming revolution in the a11y world, I've
finally sat and down and created initial packages of the at-spi2 stack
for Fedora last night [1], and wanted to share some
initial impressions I got from playing with them for a few minutes.

The good news first: I did get to hear orca speak to me.

But there were significant problems:

1. The new atk-bridge module sends my firefox into a constant 95-100% cpu loop.

2. orca constantly consumes >90% cpu while it is running.

3. I only got orca to read the panel menus to me, it didn't seem to
see any other application that I had running.

4. When it was reading the panel menus, there was a considerable lag
between me moving the focus and orca reading the menu items. Maybe
related to point 2...

Let me know if you want me to any specific debugging on these issues.

Regards, Matthias

[1] http://bugzilla.redhat.com/show_bug.cgi?id=544628
http://bugzilla.redhat.com/show_bug.cgi?id=544629
http://bugzilla.redhat.com/show_bug.cgi?id=544630
(Continue reading)

Permalink | Reply | 8 comments |
headers
Mark Doffman | 6 Dec 2009 08:49
Picon

Re: at-spi2 first impressions

Hi Matthias,

Thanks very much for taking a look at the project.

There was a glaring error in event dispatch that meant there was an idle
function running continuously.  I've just fixed and pushed the change.
(commit 30280d2d27b62c33ff)

This puts the orca / accerciser CPU usage back down to more reasonable
levels.

I'm seeing very high CPU usage when firefox starts up, and its taking a
long long time. (Although it does eventually settle down.) This
performance issue is even worse when looking at Devhelp. We have a plan
to fix this for Devhelp, and I'll take a look at what is making firefox
so slow.

Thanks again,

Mark

On Sat, 2009-12-05 at 14:51 -0500, Matthias Clasen wrote:
> Hey,
> 
> after months of ignoring the coming revolution in the a11y world, I've
> finally sat and down and created initial packages of the at-spi2 stack
> for Fedora last night [1], and wanted to share some
> initial impressions I got from playing with them for a few minutes.
> 
> The good news first: I did get to hear orca speak to me.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Mike Gorse | 7 Dec 2009 23:30
Favicon

question about GAIL TreeView cell actions

Hi all,

I've noticed that gailcell.c defines an "expand or contract" action when a 
tree view cell has other cells under it.  There is a function called 
gail_cell_type_add_action_interface which adds the action interface. 
However, it is only called by gailbooleancell.c, which is used for toggle 
cell renderers.  So one cannot expand or contract a row using an action if 
there is no cell with a toggle renderer.  I wasn't sure if this was a bug 
or not--it looked like it had been coded that way intentionally--but it 
isn't what I would expect, and it would be helpful if I could perform an 
action to expand or contract any cell that is expandable.  Does anyone 
have any thoughts or know why the code is designed the way it is?

Thanks,
-Mike G-
Permalink | Reply | 2 comments |
headers
Brian Cameron | 7 Dec 2009 23:30
Picon

Re: question about GAIL TreeView cell actions

Mike:

> I've noticed that gailcell.c defines an "expand or contract" action when 
> a tree view cell has other cells under it.  There is a function called 
> gail_cell_type_add_action_interface which adds the action interface. 
> However, it is only called by gailbooleancell.c, which is used for 
> toggle cell renderers.  So one cannot expand or contract a row using an 
> action if there is no cell with a toggle renderer.  I wasn't sure if 
> this was a bug or not--it looked like it had been coded that way 
> intentionally--but it isn't what I would expect, and it would be helpful 
> if I could perform an action to expand or contract any cell that is 
> expandable.  Does anyone have any thoughts or know why the code is 
> designed the way it is?

To me that sounds like a bug.

Brian
Permalink | Reply | 0 comments |
headers
Matthias Clasen | 8 Dec 2009 05:40
Picon

Re: at-spi2 first impressions

Here is another observation, from looking at the code:

the atk-adaptor in at-spi2-atk inherited a horrible misfeature from
at-spi's atk-bridge: it uses atexit to do 'cleanup' at exit. This is
causing the most  painful problems, see
https://bugzilla.redhat.com/show_bug.cgi?id=537843

As Owen eloquently puts it there: just say no to atexit,
deregistration needs to be automatic regardless whether the process
crashes or exits orderly.

Matthias
Permalink | Reply | 5 comments |
headers
Li Yuan | 9 Dec 2009 09:03
Picon

Re: at-spi2 first impressions

I think gtk_quit_add is a possible fix. But if an application calls the
second gtk_main after the first one quits, the application will become
inaccessible.

Li

On Mon, 2009-12-07 at 23:40 -0500, Matthias Clasen wrote:
> Here is another observation, from looking at the code:
> 
> the atk-adaptor in at-spi2-atk inherited a horrible misfeature from
> at-spi's atk-bridge: it uses atexit to do 'cleanup' at exit. This is
> causing the most  painful problems, see
> https://bugzilla.redhat.com/show_bug.cgi?id=537843
> 
> As Owen eloquently puts it there: just say no to atexit,
> deregistration needs to be automatic regardless whether the process
> crashes or exits orderly.
> 
> 
> Matthias
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel <at> gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Permalink | Reply | 4 comments |
headers
Ginn Chen | 9 Dec 2009 11:27
Picon

Re: at-spi2 first impressions

I've confirmed this problem on my box.
Firefox 3.6 failed to start.
Firefox 3.5 works fine.

I'm looking into it.

Thanks,

Ginn

On Dec 6, 2009, at 3:51 AM, Matthias Clasen wrote:

But there were significant problems:

1. The new atk-bridge module sends my firefox into a constant 95-100% cpu loop.

_______________________________________________
Gnome-accessibility-devel mailing list
Gnome-accessibility-devel <at> gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
Permalink | Reply | 0 comments |
headers
Li Yuan | 11 Dec 2009 09:31
Picon

children-changed signals in at-spi2

Hi Mark,

Ginn found a bug today that when Firefox created a new window, the
window can not be seen in Accerciser. We think the problem might be that
the "index" field of "children-changed:add" signal is missing. Actually
it is not missing, it is 0.

So I checked the code and find atk-bridge does not emit
"children-changed" signals anymore. Instead it emits "UpdateAccessible".
And on pyatspi2 side, the old cache and the new cache are compared to
determine if this is an add or a remove and send "children-change:add"
or "children-change:remove" to ATs. (Please correct me if I am wrong.)

This comes up with two questions:

1. In at-spi2-core/xml/org.freedesktop.atspi.Accessible.xml,
"object:children-changed" is one of the signals of accessible. Now
atk-bridge doesn't emit it anymore. This can be a problem if we develop
another language bindings used by ATs.

2. The index information is not passed to ATs. So there may be bugs if
ATs rely on the index number (or the AtkObject which is the second
arguments of children-changed signal). 

So is it possible to emit "children-changed" signal in atk-bridge and
use a separate listener in pyatspi2 to listen it? 

Thanks,
Li
Permalink | Reply | 4 comments |
headers
Mark Doffman | 10 Dec 2009 09:46
Picon

Re: children-changed signals in at-spi2

Hi Li,

> Ginn found a bug today that when Firefox created a new window, the
> window can not be seen in Accerciser. We think the problem might be that
> the "index" field of "children-changed:add" signal is missing. Actually
> it is not missing, it is 0.

If the index is 0 and that isn't actually the child that has been added
then it will cause problems. The index is used to add new children to
the cache even if it isn't sent in the UpdateAccessible signal.

> 
> So I checked the code and find atk-bridge does not emit
> "children-changed" signals anymore. Instead it emits "UpdateAccessible".
> And on pyatspi2 side, the old cache and the new cache are compared to
> determine if this is an add or a remove and send "children-change:add"
> or "children-change:remove" to ATs. (Please correct me if I am wrong.)
> 
> This comes up with two questions:
> 
> 1. In at-spi2-core/xml/org.freedesktop.atspi.Accessible.xml,
> "object:children-changed" is one of the signals of accessible. Now
> atk-bridge doesn't emit it anymore. This can be a problem if we develop
> another language bindings used by ATs.

There are a number of inconsistencies in the XML description of the
protocol. At the moment it doesn't properly match what is going on in
the code. At some point we will need to do a thorough analysis of it.

> 
> 2. The index information is not passed to ATs. So there may be bugs if
> ATs rely on the index number (or the AtkObject which is the second
> arguments of children-changed signal). 

I'm not sure what you mean by the index information not being passed to
the AT's. An array of objects is passed to the AT's the index
information is implicit in the array structure. Its an ordered list.

> 
> So is it possible to emit "children-changed" signal in atk-bridge and
> use a separate listener in pyatspi2 to listen it? 

I've been thinking about doing this. It would make the code in Pyatspi
simpler, and so might help out if anyone wants to write new bindings. 

Thanks

Mark
Permalink | Reply | 3 comments |
headers
Li Yuan | 13 Dec 2009 04:25
Picon

Re: children-changed signals in at-spi2

Hi Mark,

On Thu, 2009-12-10 at 00:46 -0800, Mark Doffman wrote:
> Hi Li,
> 
> > Ginn found a bug today that when Firefox created a new window, the
> > window can not be seen in Accerciser. We think the problem might be that
> > the "index" field of "children-changed:add" signal is missing. Actually
> > it is not missing, it is 0.
> 
> If the index is 0 and that isn't actually the child that has been added
> then it will cause problems. The index is used to add new children to
> the cache even if it isn't sent in the UpdateAccessible signal.

Yes, the index is always 0 even if Firefox sends out the signal with
other numbers.
> 
> > 
> > So I checked the code and find atk-bridge does not emit
> > "children-changed" signals anymore. Instead it emits "UpdateAccessible".
> > And on pyatspi2 side, the old cache and the new cache are compared to
> > determine if this is an add or a remove and send "children-change:add"
> > or "children-change:remove" to ATs. (Please correct me if I am wrong.)
> > 
> > This comes up with two questions:
> > 
> > 1. In at-spi2-core/xml/org.freedesktop.atspi.Accessible.xml,
> > "object:children-changed" is one of the signals of accessible. Now
> > atk-bridge doesn't emit it anymore. This can be a problem if we develop
> > another language bindings used by ATs.
> 
> There are a number of inconsistencies in the XML description of the
> protocol. At the moment it doesn't properly match what is going on in
> the code. At some point we will need to do a thorough analysis of it.
> 
Great.
> > 
> > 2. The index information is not passed to ATs. So there may be bugs if
> > ATs rely on the index number (or the AtkObject which is the second
> > arguments of children-changed signal). 
> 
> I'm not sure what you mean by the index information not being passed to
> the AT's.

I mean Firefox sets the index to 2 or other numbers, and sends out the
children-changed:add signal. But on Accerciser side, index is always 0.
So the value of index is not correct.

>  An array of objects is passed to the AT's the index
> information is implicit in the array structure. Its an ordered list.

How the list is passed to AT's? I don't see the children-changed signals
have such a field. Or do you mean ATs should get the list manually when
there is a children-changed signal?

> > 
> > So is it possible to emit "children-changed" signal in atk-bridge and
> > use a separate listener in pyatspi2 to listen it? 
> 
> I've been thinking about doing this. It would make the code in Pyatspi
> simpler, and so might help out if anyone wants to write new bindings. 

Yes.

Thanks,
Li
Permalink | Reply | 2 comments |

Gmane