Created attachment 69060 [details] [review]
Patch to potentially fix the problem. See comments below.

The problem is that the code in _getSpeechForTableCell(0 in
speechgenerator.py was not speaking the name of the table cell
if that cell already had focus. The equivalent code in
_getBrailleRegionsForTableCell() in braillegenerator.py did not
have such a limitation and the braille line had the correct utterance
in it.

The concern is whether removing the check in the speech code to see if
it's already focused will cause multiple occurances of the speech
describing the current table cell.

I've tried out this change with gaim, gtk-demo and evolution and it
seems to worl well. Will, okay to check it in?

The check for "already_focused" is to prevent Orca from being overly verbose when doing something such as announcing state changes to the currently focused item.  For example, instead of hearing the name of a check box over and over again, we'll only hear "checked" and "unchecked" when pressing the space bar to change the state of a check box when it has keyboard focus.  This reduction of speech is useful because speech is a temporal interface and chatty interfaces quickly become annoying.

We don't do this verbosity check in braille because it is not a temporal medium and keeping the spatial arrangement of the output relatively constant is a good thing (e.g., the only thing that changes on the display is the one cell containing the state of the checkbox when you change its state).  

So...to test how well this patch works with the intended use of "already_focused", you might bring up the "Tree Store" demo under the "Tree View" node in gtk-demo.  Move to a checkbox under the "Alex" column and press space to check and uncheck it.  You should only hear "checked" and "unchecked" if you monkey with it after you give it focus.  This may not be a super test, though, as I think what we're also trying to not speak any label for the checkbox: none of the checkboxes in the table in the "Tree Store" demo have labels.

In any case, if things look good after more testing, I'd say check it in, but maybe also include a comment in the code (perhaps even referring to this bug) for why we are not looking at already_focused.

Tree Store demo seems to still work nicely using the test you
describe above. Change (plus comment) checked into CVS HEAD.
Closed as FIXED. If something has deteriorated then we can 
reopen and reinvestigate.

Helps to remember to close it. Thanks Will.

Reoping for now. Looks like I didn't check the fix in
(thanks Joanie). It's at home. I'll do it this after when
I get back to that machine.

Changes committed to CVS HEAD. Really. I mean it this time.
speechgenerator.py should be at revision: 1.71. Closing as
FIXED.

Thanks Rich!  I appreciate it.  I got the fix this time (I even looked at the version number inside speechgenerator.py and it's definitely today's).  And, oh man, I don't want to say this but.... it didn't fix the problem.  

If you look at the original steps I submitted, here's how things HAVE changed:
---
Before:  2. Use Shift Left Arrow to collapse it.  Orca correctly announces "collapsed"

Now:  2. Use Shift Left Arrow to collapse it.  Orca correctly announces the item name followed by "collapsed" (e.g. "Interface collapsed")
---

Unfortunately, what has NOT changed are:
---
3. Use Shift Right Arrow to expand it.  It expands, but Orca says nothing.

4. Arrow down to get off of that item and then arrow back up to it. 

Actual results:
Orca reads/displays the name of the item, but states it's collapsed when in
reality it's expanded.

Expected results:
Orca would read/display the state correctly. :)
---

I can still reliably reproduce this in the preferences dialog of Gaim 1.5.1 and in Evolution 2.6 (on one of my two machines).  Sorry to be the bearer of bad news.... :(

Joanie, I tested this with gaim (v2.0.0beta2)
-- the version of gaim on my Solaris machine -- and
didn't see the failure. When I expand the tree items
it says the name of the item and then "expanded".

I also tried it yesterday with evolution v2.6.1 and
it worked fine. Retrying it again with that version of
evolution today, and I'm seeing the problem you're seeing.

I'll reopen it and investigate further.

Thanks.

Thanks!  Regarding Gaim, I don't have the issue with 2.0 (using beta 3).  It's specifically in 1.5.1 and in the Preferences dialog.  

BTW, I'm using Evolution 2.6.1 as well.  Not sure where the 1 went in my previous comment....

I've reinstated the "and (not already_focused)" test in
_getSpeechForTableCell() in speechgenerator.py. This is 
needed to prevent the name being repeated when it's the 
same table that has focus. 

There are still problems will table cells though (as Joanie
reports here). Need to investigate further.

By the Bugzilla definition of critical [1], this bug isn't
critical. Bumping it down a notch. Thanks for the clarification 
Will.

[1] http://bugzilla.gnome.org/page.cgi?id=bug-status.html#bug_severity

I've been investigating this one a little further.
I'm using Evolution 2.6.1 and latest Orca from CVS HEAD.

* Start Orca
* Start Evolution
* Get the focus to my "rich.burridge@sun.com" top level
  tree table entry in the mail folder tree table on the
  left side which is initially in an expanded state.
* Hit Shift-Left Arrow to collapse it.
* Hit Shift-Right Arrow to expand it.

The initial state of the tree table cell is correctly spoken.
Doing the Shift-Left Arrow gets an "object:state-changed:expanded"
event, and the state is correctly spoken (collapsed).
Then doing a Shift-Right Arrow doesn't generate another
"object:state-changed:expanded" event, so Orca is unable to speak
the new state.

Here's the full set of events for the actions above.

DEQUEUED EVENT window:activate <----------
DEQUEUED EVENT object:state-changed:focused <----------
DEQUEUED EVENT object:state-changed:active <----------
DEQUEUED EVENT focus: <----------
DEQUEUED EVENT object:state-changed:showing <----------
DEQUEUED EVENT object:children-changed:add <----------
DEQUEUED EVENT window:create <----------
DEQUEUED EVENT object:state-changed:visible <----------
DEQUEUED EVENT object:state-changed:showing <----------
DEQUEUED EVENT window:destroy <----------
DEQUEUED EVENT object:state-changed:visible <----------
DEQUEUED EVENT object:state-changed:iconified <----------
DEQUEUED EVENT object:state-changed:iconified <----------
DEQUEUED EVENT object:state-changed:expanded <----------
DEQUEUED EVENT object:property-change:accessible-value <----------
DEQUEUED EVENT object:property-change:accessible-value <----------
DEQUEUED EVENT object:state-changed:showing <----------
DEQUEUED EVENT object:children-changed:add <----------
DEQUEUED EVENT window:create <----------
DEQUEUED EVENT object:state-changed:visible <----------
DEQUEUED EVENT object:state-changed:showing <----------
DEQUEUED EVENT window:destroy <----------
DEQUEUED EVENT object:state-changed:visible <----------
DEQUEUED EVENT object:state-changed:iconified <----------
DEQUEUED EVENT object:state-changed:iconified <----------
DEQUEUED EVENT object:state-changed:showing <----------
DEQUEUED EVENT object:children-changed:add <----------
DEQUEUED EVENT object:state-changed:visible <----------
DEQUEUED EVENT object:state-changed:showing <----------
DEQUEUED EVENT object:children-changed:add <----------
DEQUEUED EVENT object:state-changed:visible <----------
DEQUEUED EVENT object:property-change:accessible-value <----------
DEQUEUED EVENT object:property-change:accessible-value <----------
DEQUEUED EVENT object:property-change:accessible-value <----------
DEQUEUED EVENT object:property-change:accessible-value <----------

I'll also attach a transcript of the Orca debug for this run.

Note that this isn't always reproducable. Sometimes it
works just fine. Sometimes it doesn't.

I now plan to try to generate a small Python script to
replicate the problem and pass it over to the Evolution folks
for further investigation.

Created attachment 70210 [details]
Transcript of the Orca debug events for the actions described in comment #13 of this bug.

Created attachment 70220 [details]
Standalone Python script to replicate the problem.

Created attachment 70221 [details]
Debug output from the 347228.py script when trying to reproduce the problem.

I've attached a standalone Python script that can be
used to replicate the problem.

The instructions to reproduce this are:

1) Start up an xterm
2) In that xterm, run:
     % script
     % python 347228.py
3) In a separate gnome-terminal window (or via the Launch menu)
   start up Evolution in mail view.
4) Use the mouse to give focus to a top level tree item in
   the mail folder list on the left side. (Make sure that
   that tree table item is currently expanded).
5) Hit Shift-Left Arrow to collapse that tree node.
6) Hit Shift-Right Arrow to expand that tree node.
7) Repeat steps 5) and 6) several times.
8) Hit F12 to exit.
9) Type "exit" in the xterm window to save the transcript of
   debug output.

I also attached a sample output from such a run.
Look for lines that start with "object:state-changed:expanded".
There should be such an event every time I've either typed
Shift-Left Arrow or Shift-Right Arrow. This is not happening.
You can find the keyboard events by looking for lines that
start with "keystroke".

Transferring to the Evolution team for further evaluation.

Adjusting the summary line, adding in the Sun folks in China
and adding in the "accessibility" keyword.

Also resetting priority and severity to normality.

I have tested this with nv47 + evolution-2.8, as you can see in the attachment, evolution send out the expand signal everytime, and orca works very well with evolution. 

Created attachment 72582 [details]
debug output: nv47 + evolution-2.8

And I tested this on nv46 + evolution-2.6.2, orca also works fine.
BTW: the tree is gtktreeview, so maybe the version change of gtk+ or gail will fix this problem. Which build are you using?

I've been using evolution v2.6.1 on Solaris Nevada build #34 with
vermillion build #42.

Joannie, are you still seeing this problem with Ubuntu Edgy? If so,
what is the version of Evolution there?

Thanks.

I am not seeing this problem in Edgy.  It's version 2.8.0.

Thanks Joanie. Li Yuan, this bug can probably be closed out now.

Reopen the bug. I can reproduce this when there is two level sub-folder. It is a Gailtreeview bug. When one press "shift + left", gail_tree_view_expand_row_gtk is called many times. And the idle_expand_path is replaced by its child before idle_expand_row get chance to be called. So Evolution can not emit "object:state-changed:expanded" on the right tree item. Making patch...

Hi Li:

I suppose a patch to fix this will have to be quite complex.  The idle handlers must be removed (via g_source_remove) in order to avoid crashes in gail (this has been a source of much trouble in gailtreeview.c) so we'll need some sort of list of queued idle handlers, and a way of determining when they should be removed from the list, making sure they are called in the right order if that's important, etc.

Hi Bill,
I guess the crash bug you said is #336311. When gail_tree_view_expand_row_gtk is called the second time, it will change the value of idle_expand_path. So no matter how many times the idle function is called (the number will be one after you commit http://bugzilla.gnome.org/attachment.cgi?id=72802&action=view), the root-path of the expand event will never emit the signal.

I think call set_expand_state (tree_view, tree_model, gailview, path, TRUE) in idle_expand_row should solve the problem, but seems it can not find its ancestor.

So I think maybe we can change idle_expand_path to a list to store all the path need to be set_expand_state?

Just found a little bug in set_expand_state, can find ancestor now. Create a patch to fix this bug.

Created attachment 73023 [details] [review]
patch to fix this bug

Thanks a lot for finding this, Li!  Excellent detective work.

I've committed your patch.  p.s. - do you have cvs commit priveleges yet? I suggest you ask for them, I'll confirm that you should have them for gail.

Thanks for review Bill. I have got the commit privilege already from evolution maintainer. I think I can commit gail patch too :)
Do you have a plan to branch gail for gnome-2-16?