This is a duplicate of bug #156466. If this bug is still present after applying
patch for it, please reopen.


*** This bug has been marked as a duplicate of 156466 ***

sorry, both patches in bug 156466 cannot fix my problem.
My real problem is, when focus into a table, gnopernicus Speech only speak the
current focused table cell (Or 3 cells) instead of the whole table line. Brlmon
can show the whole table line.  The table is uneditable, user can only user
up/down arrow button to change focused line. User cannot use left/right arrow
button in this case.
How to make gnopernicus Speech to speak out the whole table line? Can we have a
user option for this?

I think this is by design.  Most speech users won't want the verbosity of that
much information.

Yes, I agree. But make it an option will make gnopernicus Speech more flexible.

The presentation can be change in presentation files. 
Peter, what about having existing behaviour only in "default" presentation mode
and the requested (by Harry Lu) presentation in "verbose" mode?

I agree with this suggestion.

That seems reasonable to me (verbose in verbose mode).

But that raises another question: where is this stuff doing to be documented?  I
know Dragan is reviewing Irene's manual now; I haven't seen it myself yet.  Does
it cover things like this?  If not, it probably should...

In the gnopernicus manual I got from Irene ,the presentation prefernces section
looks like this:
*************Start of section
Presentation Preferences

Click on Presentation in the Preferences window to open the Presentation
Preferences dialog.

You can select the following functionality:

    * Verbose
    * Default  
**************End of section

I think that:
1) this isn't a P1/P2 bug;
2) the summary should be changed, because it doesn't have anything (really) to
do with braille monitor, it's just an RFE for more verbose table presentation;
3) I doubt whether it would be a good thing most of the time.

also:

4) if important table information is not otherwise available to the speech user,
then I suggest the proper fix is somewhere else (either in the application's
keyboard navigation or in gnopernicus review modes).

If #4 is the problem, then high-priority bugs should be logged against the
application(s) which fail to allow the user to navigate to important information.

Created attachment 37493 [details] [review]
proposed patch

The patch seems reasonable.  What happens in other table situations like
StarOffice Calc, StarOffice file open, and Swing JTable?  Assuming the behavior
is good in those apps, I think this is reasonable to apply.  Note though, that
this is really a kind of general band-aid whose real solution is scripting.

remus draica, will this patch be committed into CVS?
BTW, it cannot be applied into current CVS because of context changes.

3) I doubt whether it would be a good thing most of the time.

Harry, I said in comment #9 above:

"also:

4) if important table information is not otherwise available to the speech user,
then I suggest the proper fix is somewhere else (either in the application's
keyboard navigation or in gnopernicus review modes).

If #4 is the problem, then high-priority bugs should be logged against the
application(s) which fail to allow the user to navigate to important information."

In the Evolution case I think evolution itself seems to be missing some keyboard
navigation.  I think the gnopernicus patch may have too many side-effects to
apply, for instance excessive verbosity for other applications.  But I have been
waiting for your response to how Evolution keyboard navigation can address this
issue; we need to be able to navigate within the table line via the keyboard, I
think.  This would also solve the problem, without changing gnopernicus behavior
for other applications.

Bill, I see your point.

In Evolution, the mail list is implemented using E-Tree's line mode. It means 
the cursor can only be moved from row to row, and not from column to column.
Just changing the mode will impact Evolution's normal behavior, too. 

We have a very hacky patch to make E-tree's cursor can be moved from column to 
column if a11y is enabled, but we are not sure whether community will accept it.
We will send out the patch for review and have a try.

Harry:

Another possibility has to do with the behavior of E-tree.  It seems at the
moment that gnopernicus is getting focus or active-descendant-changed (not sure
which) when the etree line changes.  Based on gnopernicus behavior, it seems
that one cell in the etree is 'active' or 'focussed', but the other cells on the
same line cannot be reached via keyboard navigation.

This causes an inconsistency.  Conceptually speaking, when in 'line mode', it
seems that the active and/or focussed item is the table _line_, and not the
table cell.  If focus is on one cell, then all cells should be separately
reachable via the keyboard (as your "hacky patch" does).  But it sounds as
though the more conceptually correct fix is for the focus to be on the table
line instead.

I am not sure if this is feasible with the current atk implementation of etable;
I'll look at the ATK hierarchy and see what it looks like.  Since in our
AtkTable interface, table "lines" are not separate AtkObjects, it may be
difficult to implement this.  One thing that would NOT be correct is to have
multiple objects with state FOCUSSED at the same time, or to emit multiple
active descendants.

I think our current AtkTable concept requires, in effect, that all table cells
be navigable.  It would be OK if the keyboard navigation within a line (from
column to column) required the use of 'control', i.e. Control-rightarrow,
Control-leftarrow.  Possibly this would be more acceptable to the community.

Bill,
The community accepted our patch and we just checked in the patch. So this 
won't be an issue for evolution.
See bug: 314352

Bill, Harry, is this bug still valid or I can close it?

Remus, it is not needed for evolution for now.
I think you can close it if you want.

Changing to an RFE for "speak whole line" command of some sort, for tables.