GNOME Bugzilla – Bug 153920
Item values repeated twice by screen reader
Last modified: 2004-12-22 21:47:04 UTC
Installed JDS Release 3 (GNOME 2.6)on HP intel P4 machin. 1. Start Gnopernicus,enable acessibility support,logout and login again. 2. Start Gnopernicus again. 3. Open Gedit. 4. Click on 'Preferences' from Edit menu. 5. In the Preferences window click on 'Syntax Highlighting' Tab. 6. In the resulting window click check the option 'Foreground' and click on the color button next to it. 7. In the 'Pick a color' window navigate through the items Observation: Screen reader reads the text and the value of the focusssed item but while moving to the next item it first reads the value of the previous item and then it reads the next items text and value.This is very much confusing for user.
Created attachment 32067 [details] [review] proposed patch
remus, can you explain what is going on in the 'else' statement which this patch modifies? I don't understand why you would present any information at all if the object is not watched, and not focussed...
In the case of else, if event is for watched object, then the speech output has a higher priority (the events for watched object should not be interrupted by focus-tracking events). Otherwise the event is for focused object. NOTE: When gnopernicus starts to present an object, the object may be focused (exception for watched objects). But, while gnopernicus is building XML presentation string, the object may change its state. This situation is happening here. If an event for an object which doesn't have FOCUSED state is proposed for presentation then it is for an watched object (in current implementation). In this bug, the state was changing during XML construction, and, the logic was supposing that the event is for an watched object, and it was sent to speech with a higher priority. So, a better detection of events for watched object was needed here. A better solution is to not present events like this (for an unfocused and unwatched object) at all. I will check the behaviour for this solution. Event from at-spi, when (only) tabbing from one spin-button to another: selection-changed from current _focused_ object focus for the _new_ _focused_ object. These 2 events are send by application one after other, with no delay between. The situation described above (at NOTE) occurs in this case.
Created attachment 32102 [details] [review] a different proposed patch
Either patch looks OK to me; please apply whichever one you think is working better in tests.
Comment on attachment 32102 [details] [review] a different proposed patch This patch work better in my oppinion. It was applied to cvs head and gnome-2-8 branch.