GNOME Bugzilla – Bug 141476
nsufficient reporting on radio buttons
Last modified: 2005-03-21 13:42:53 UTC
TO REPRODUCE: o Open StarOffice and go to Tools - Options - StarOffice - Print o Open Gedit and go to Edit - Preferences - Editor; RB Undo o Listen to speech output RESULT: SO: When focussing a radio button gnopi reports the label and the name of the selected button. When changing the selection gnopi only reports the changed status from unchecked to checked and not the name of the button. Gedit: When focussing the radio button gnopi reports the role and the selected button. When changing the selection gnopi reports nothing.
Created attachment 27358 [details] [review] proposed patch Ralf, can you confirm to me that now, when user moves from one RB to another the state of the second will change also? Till now a focused RB could have been unchecked, but this seems to be not the behaviour anymore.
In SwingSet2 from j2sdk 1.5.0, is an example with radio buttons that can be focused without changing their status (from unchecked to checked). In SOffice this situation can't be found, every movement from a radio button to another is done whit unchecking the first one and checking the current. In gedit is the same situation as in SOffice.
What is the status of this bug? Should the patch be applied?
With the patch from comment #1 applied the output when user moves between radio buttons is the desired one for both SO and gedit. I believe the patch should be applied in CVS. Bill, can you check the patch?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Is the behavior with SwingSet2 also the desired behavior? How about gtk-demo's radiobuttons? (or test-gtk's) ?
I've checked the patch with SwingSet2 and the behavior is not the desired one because there are radio buttons which can be focused without changing the state. With this patch applied, the state change wont be reported.
Created attachment 37491 [details] [review] proposed patch
Comment on attachment 37491 [details] [review] proposed patch does this patch compile?
Created attachment 37588 [details] [review] reoworked patch I had some messages to see if some parts of the new code are called. I skiped a part from a multiline instruction when I deleted them.
Comment on attachment 37588 [details] [review] reoworked patch please remove the omf.make and xmldocs.make changes.
BAUM - can you please describe the event stream in this case in GTK+, StarOffice, and Swing?
Events and states obtained when changing focus: GTK+: state-changed:checked old_focus FOCUSED (1) state-changed:checked new_focus FOCUSED+ARMED+CHECKED (2) focus new_focus FOCUSED+ARMED+CHECKED (3) SO: state-changed:checked old_focus FOCUSED (4) focus new_focus FOCUSED+CHECKED (5) state-changed:checked new_focus FOCUSED+CHECKED (6) JAVA: focus new_focus FOCUSED (7) Events obtained in JAVA when pressing space on the new focused object to change its state: state-changed:checked prev_checked (8) state-changed:checked crt_checked FOCUSED+CHECKED (9) Events which shoud be reported to user are: GTK+ 3 SO 5 JAVA 7 then 9
Created attachment 37887 [details] [review] reworked patch
Patch in comment #14 is better and smarter than the one in comment #10. When focus event for a radio button is received, its state is retained. Then, when a state-changed:checked event is received it is presented oly if the state was uncecked and now state is checked. This way, unwanted state-changed:checked events in gtk and SO are ignored and only those from JAVA are presented.
Remus, I agree that your new logic is looks good based on the above table - at least at first glance. It seems pretty robust to me, also (i.e. don't present state-change events for things if the state hasn't "really" changed from the value received on focus.) HOWEVER - I wonder, how are you getting the 'state info' which you present in the table above? I presume you're getting it from at-spi calls back into the object, which is subject to the same old race condition issues, isn't it? Are you obtaining this state info inside the focus-event-handler, or at idle?
All states are obtained in the callback, not in an idle.
Comment on attachment 37887 [details] [review] reworked patch Patch committed on cvs head.