GNOME Bugzilla – Bug 301924
speech doesn't report single result in Find Files
Last modified: 2005-05-12 09:26:21 UTC
Distribution/Version: JDS Rel3 B33 Using gnopernicus 0.10.5 - Start gnopernicus with speech enabled. - From the main menu go to "Find Files" - In the "name contains" textfield, type in something that will produce just one result and press <return> - <tab> to the table. - With Focus on the table header, press <down> Notice that the single result is focussed. - Press the <down> key again. Notice that, even though the result is now highlighted, there is no spoken report of the table line. To get a report, the user has to press either <left> or <right>, which is not an intuitive thing to do.
see bug 163949; I'll close 163949, since this bug describes only the remaining problem.
The first cell from the table line has two children. When you move for the first time to the table line, this is 'marked' by a dashed line rectangle and the first cell (or its children) doesn't have 'selected' or 'focused' state. If now press down or up key, the line is 'marked' by a blue rectangle (the line it's highlighted) and, in this case, the first cell has 'focused' and 'selected' state, but its children have only 'selected' state. In case of tables, from the 'selected' children, gnopernicus reports only the 'focused' children. Because of this, the line is not reported by gnopernicus.
Oana - so at the end of the operations in comment #2, the table lines cells have both SELECTED and FOCUSSED? If that's true, then gnopernicus should read the children of the first cell, regardless of whether then have state FOCUSSED or not.
When the single table line is highlighted, the first cell has 'SELECTED' and 'FOCUSED' states and its children have 'SELECTED' state. In case of no 'FOCUSED' cell, the first 'SELECTED' cell which is 'VISIBLE' and 'SHOWING' will be reported by gnopernicus, but the problem is that AccessibleSelection_getNSelectedChildren returns 0, even if the children have 'SELECTED' state. (see comment #6 from bug #163949)
Oana: are you absolutely certain that AccessibleSelection_getNSelectedChildren returns 0 when the single table line is highlighted, the first cell has SELECTED and FOCUSED states, and its children have SELECTED? There doesn't seem to be a bugzilla bug on this issue if that is true; would you please file one? If on the other hand the statement above doesn't exactly describe what is going on, please clarify.
I was wrong in comment #4. When I move first time in the table, the table line is marked by a dashed line rectangle. In this case, AccessibleSelection_getNSelectedChildren returns 0. This is correct, there is no SELECTED cell in the table. Because there is no SELECTED cell, gnopernicus can't report the table line.
The problem is that is this case, the first table line is "dashed", but not selected and it contains a FOCUSED cell. Gnopernicus tries to find a FOCUSED cell among those selected.
Created attachment 46006 [details] [review] proposed patch This patch, in case of 0 selected children will check if the first cell of the table is FOCUSED.
in comment #7, Remus, the table line IS SELECTED at the end of the 'second' press of the down arrow key. So this patch doesn't make sense. Please repeat the steps Oana describes in comment #2, and tell me if you understand the situation better - the bug being reported here is that gnopernicus says nothing when the first table line goes from "dashed line around it, but not selected" to "selected", i.e. this change of state is unreported by gnopernicus.
Bill, the line is "selected" for user after first press. My patch reports the line after first press. This behavior is better than the request (present the line after the second press) because: 1. user is on the table header 2. left/right arrow is pressed -> a new table column header gets the focus (and it is reported) 3. down arrow is pressed -> the first (single) line gets _focused_ but not _selected_ (_nothing_ is reported, so the user still has the impression he is on the header) 4. user press left/right again -> the new selected cell is reported, not a new column header. This behavior is confusing for user.
Created attachment 46059 [details] [review] reworked patch
Remus: the line is NOT "selected" for the user at the time I am referring to, it is only "focussed". Perhaps we are still misunderstanding each other. The behavior you report above is the _CURRENT ACTUAL_ behavior of the treeview widget, and we MUST be faithful to this in what we report to the user. We should not report that the first line is 'selected' when in fact it is not; however we MUST report that the line is selected when it is. There is a very real change in the state of the table between steps 3 and 4 above; we need to report the event when the first table line changes from 'focussed' to 'selected', since this change is very significant to the behavior of the table (for instance, this change determines what happens in a file selector when the user presses 'ok')
>There is a very real change in the state of the table between steps 3 and 4 >above; we need to report the event when the first table line changes from I agree that. >Remus: the line is NOT "selected" for the user at the time I am referring to, >it is only "focussed". At this point user can interact with that line. How this should be presented?
While I think a good argument can be made that the "focused but not selected" state isn't particularly meaningful and should be removed, Bill's point I think carries the day: Gnopernicus should say something meaningful in this situation. You can see the same situation with a search that returns multiple items to populate the table as well. The only difference is that in that case down arrow will select the second row of the table (bug against table Bill?). Here's a proposal: when focus comes to a table (with a visual focus indicator on the first row that is NOT selected) have Gnopernicus tell you not only that you are on a table, but how many rows are in the table, and what the first line of the table is (assuming the first line is what has focus indication) and that this table line is NOT selected. That way you get more and useful information, not just "Table <table name>". You also are told where you are, but aren't told that it is selected. Then pressing an arrow key will cause a selection, which is spoken as normal. John - will this satisfy you? Also, as a separate comment (and likely a separate bug, sigh): when I tab to focus to the table header, "Name" is the colum that has focus. Gnopernicus reads the entire set of table columns to me. Pressing right arrow brings keyboard focus to the Folder table column, but Gnopernicus fails to tell me this - it simply re-reads the entire set of table columns to me again. BAUM - is there a bug for this latter behavior yet? If not, could you please file one. I think speech should tell you specifically which table column is selected. Perhaps something like: "Name column of table colums 5 items Name Folder Size Type Date Modified". This could be repeated for right arrow presses. While verbose, the most interesting information is always spoken first so a user can interrupt it quickly.
Gnopernicus should report only the new cell or column-header when moving in same line or in the table column headers. This behavior has support in gnopernicus and it used to work. But, another patch (wrong applied?!?) made this code to not be called anymore.
Created attachment 46085 [details] [review] proposed patch This patch solves the problem of wrong(?!) applied patch.
Peter: "The only difference is that in that case down arrow will select the second row of the table (bug against table Bill?)." This is bugzilla #166553
Bill, will bug #166553 be fixed?
bug 166553 will probably be patched in the Sun release, possibly in the next week or so.
In this case, all patches are useless. The case described by John is not possible (with bug 166553 fixed). The only usefull patch is the one in comment #16.
166553 turns out to be the wrong bug number. Please ignore it. The sun-internal bug describing the problem is 6216954, which erroneously points to the bugzilla bug I mentioned.
Closing th bug, since the described problems are now subjects of other bugs.
Bug should not have been closed as FIXED, since it hasn't been! Closed bug as OBSOLETE since it has been replaced by two new bugs - however, personally, I don't think this bug should have been closed at all, as it has dependencies on those two unfixed bugs. Please don't close things as FIXED if they haven't been fixed, i.e. if the originally reported problem is still present. Thanks.