After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 141476 - nsufficient reporting on radio buttons
nsufficient reporting on radio buttons
Status: RESOLVED FIXED
Product: gnopernicus
Classification: Deprecated
Component: speech
unspecified
Other Linux
: Normal normal
: ---
Assigned To: remus draica
remus draica
AP2
Depends on:
Blocks:
 
 
Reported: 2004-04-30 09:20 UTC by Ralf Unger
Modified: 2005-03-21 13:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed patch (791 bytes, patch)
2004-05-04 08:11 UTC, remus draica
none Details | Review
proposed patch (2.04 KB, patch)
2005-02-15 13:57 UTC, remus draica
needs-work Details | Review
reoworked patch (3.59 KB, patch)
2005-02-17 11:45 UTC, remus draica
needs-work Details | Review
reworked patch (1.92 KB, patch)
2005-02-24 11:45 UTC, remus draica
accepted-commit_after_freeze Details | Review

Description Ralf Unger 2004-04-30 09:20:07 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.
Comment 1 remus draica 2004-05-04 08:11:28 UTC
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.
Comment 2 Alexandra Telescu 2004-06-11 10:36:06 UTC
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.
Comment 3 Dana Ormenisan 2004-09-30 12:04:07 UTC
What is the status of this bug? Should the patch be applied?
Comment 4 Dana Ormenisan 2004-10-08 13:17:27 UTC
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?
Comment 5 Calum Benson 2004-10-21 16:46:47 UTC
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs.
 Filter on "SUN A11Y SPAM" to ignore.
Comment 6 bill.haneman 2004-11-05 14:33:58 UTC
Is the behavior with SwingSet2 also the desired behavior?  How about gtk-demo's
radiobuttons? (or test-gtk's) ?
Comment 7 Dana Ormenisan 2004-11-05 15:20:51 UTC
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.
Comment 8 remus draica 2005-02-15 13:57:37 UTC
Created attachment 37491 [details] [review]
proposed patch
Comment 9 bill.haneman 2005-02-15 14:35:04 UTC
Comment on attachment 37491 [details] [review]
proposed patch

does this patch compile?
Comment 10 remus draica 2005-02-17 11:45:23 UTC
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 11 bill.haneman 2005-02-21 17:55:50 UTC
Comment on attachment 37588 [details] [review]
reoworked patch

please remove the omf.make and xmldocs.make changes.
Comment 12 korn 2005-02-21 18:07:09 UTC
BAUM - can you please describe the event stream in this case in GTK+,
StarOffice, and Swing?
Comment 13 remus draica 2005-02-24 11:36:31 UTC
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
Comment 14 remus draica 2005-02-24 11:45:25 UTC
Created attachment 37887 [details] [review]
reworked patch
Comment 15 remus draica 2005-02-24 11:52:45 UTC
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.
Comment 16 bill.haneman 2005-02-24 12:59:06 UTC
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?


Comment 17 remus draica 2005-03-07 15:08:21 UTC
All states are obtained in the callback, not in an idle.
Comment 18 remus draica 2005-03-21 13:42:25 UTC
Comment on attachment 37887 [details] [review]
reworked patch


Patch committed on cvs head.