GNOME Bugzilla – Bug 155955
The summary of task can not be read.
Last modified: 2004-12-22 21:47:04 UTC
Bug originally reported by flame.ding@sun.com 10/19/04 09:10 GMT -------------------------------------- Steps to reproduce: 1. Launch gnopernicus. 2. Launch Evolution and go to task component. 3. Navigate and review tasks. Expect resultes: The summary of the task should be read. Actual resultes: The summary of the task can not be read. flame.ding@sun.com 10/19/04 09:10 GMT Comments -------- Summary can be displayed in brlmonitor, but can not be read by speech. So this is a bug related to gnopernicus-speech. tim.miao@sun.com 10/19/04 10:57 GMT How do I get Summary to display in brlmonitor? padraig.obriain@sun.com 10/20/04 07:57 GMT
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
No, this bug is not related to gnopernicus-speech. In case of changing table lines, brlmon and speech have two different ways of giving the information to the user: - brlmon shows the current visible line - speech outputs is composed by: - the cell before the current focused one, - current focused table cell - the cell after the current focused one. So if the table has more that 3 columns, brlmon shows all the visible cell from the current row, but the speech reports only 3 cells. The current focused cell is considered to be the first cell of the current line who has the state 'FOCUSED'. This is the expected behavior in case of table. In this case...there are more that one cause of the bug: 1. For all other types of table gnopernicus receives an 'object:descendant-change' event for the table and this makes gnopernicus generate the output previous described (the expected one). In this case gnopernicus receives this event, but it receives also a redundant 'focus' event for the current focused cell. This should NOT happen. Only one event should be generated, the two events must exclude each other. This is the first bug, but it doesn't belong to gnopernicus. So, gnopernicus sends for speech the string based on the first event and then the string based on the second one which interrupts the first output and the user can here, only the report for the focused cell. 2. Even if the 'focus' event will be removed the output will not be the expected one. In the case described in the bug, a tree table cell remains 'FOCUSED' even if it is not longer the current focused one, meaning that, if a cell is once focused it keeps this state until the application (evolution) is closed. Because of this there could be more that one 'focused' cell in the same row, at one moment. This is again NOT a gnopernicus bug, it belongs to evolution, I think. So, gnopernicus searches for the first cell from the current row, who has the state 'focused' and it finds: - the current focused cell if no cell placed before it was once focused, in the current row or - the first cell of the row who was once focused. Starting from this cell the output for speech is created. In this case: - if you focused once the 'type' cell of one task, you will never here the 'summary' for that task, even if the current focused cell is the 'summary' cell. - else if you focused once the 'complete' cell, all the row is reported - else if you focused only the 'summary' cell, the 'complete' and 'summary' cells are reported.
Bug: http://bugzilla.ximian.com/show_bug.cgi?id=68675 was files against evolution for the second issue (2 of comment 2) of this bug.
Bug: http://bugzilla.ximian.com/show_bug.cgi?id=68681 was filed to evolution for the fiest issus (1. comment 2) of this bug.
There ware two issues for this bug. For each of them, a nongnopernicus bug was filed. So, I am closing this bug as 'NOTGNOME'.
*** Bug 157428 has been marked as a duplicate of this bug. ***