GNOME Bugzilla – Bug 473420
Orca speaking an extra "seconds" for the Preferences dialog.
Last modified: 2007-09-07 16:13:41 UTC
1. Startup Orca 2. Startup pidgin. 3. Give focus to the pidgin application and press Insert-Control-Space to bring up the Orca application specific preferences. After the Orce Preferences dialog appears, Orca speaks: "Orca Preferences for pidgin seconds". It would appear the logic for handling "unattached" labels for a dialog has changed recently and it's now speaking the "seconds" label to the right of the Update Interval combo box on the speech pane.
> After the Orce Preferences dialog appears, Orca speaks: > > "Orca Preferences for pidgin seconds". > > It would appear the logic for handling "unattached" labels for a dialog > has changed recently and it's now speaking the "seconds" label to the > right of the Update Interval combo box on the speech pane. I'm not sure what might have changed in this space. :-( Is it possible that we just didn't notice this behavior until now? Can you do some more debugging to see why this is happening? Putting a debug.printStack(debug.LEVEL_OFF) in default.py:findUnrelatedLabels might be the spot, and I suspect it would be speechgenerator.py:_getSpeechForAlert that would be the thing doing this.
> I'm not sure what might have changed in this space. :-( Is it possible that > we just didn't notice this behavior until now? That would be my guess. On my Solaris box I have the currently shipping version of Orca. That was pre-progress bar updates and "seconds" is (obviously) not announced. But if I give focus to the Magnifier pane, get out of the Orca Preferences dialog, and then return to the Orca Preferences dialog, Orca tacks on "pixels pixels".
Created attachment 94939 [details] Orca debug output showing where problem is. > Putting a debug.printStack(debug.LEVEL_OFF) in > default.py:findUnrelatedLabels might be the spot, > and I suspect it would be speechgenerator.py:_getSpeechForAlert > that would be the thing doing this. Confirmed. What approach should be taken to fix this Will?
> > Putting a debug.printStack(debug.LEVEL_OFF) in > > default.py:findUnrelatedLabels might be the spot, > > and I suspect it would be speechgenerator.py:_getSpeechForAlert > > that would be the thing doing this. > > Confirmed. Thanks! > What approach should be taken to fix this Will? I think that label for/by relations should be set up for the offending labels in the Orca Preferences GUI.
> I think that label for/by relations should be set up for the offending labels > in the Orca Preferences GUI. So how would this work? On the speech pane we currently have: Label spin button Label -------------------------------------- Update Interval: (( setting )) seconds The spin button button (I thought) could only be LABELLED_BY one label. Did I get this wrong? Can you give it two LABELLED_BY relationships? If so, which one will it speak first?
> The spin button button (I thought) could only be LABELLED_BY > one label. Did I get this wrong? Can you give it two LABELLED_BY > relationships? I'm pretty sure an object can be labelled by more than one thing, and default.py:findDisplayedLabel handles this (though the name "findDisplayedLabel" is a bit misleading). > If so, which one will it speak first? The order in which the list of labels is presented is dependent upon the order in which they are found via the AT-SPI relations value. We could potentially make the order dependent upon their 2D location on the display, but that would be a separate RFE.
Created attachment 94947 [details] [review] Patch to SVN trunk to fix the problem. Not committed yet. I don't see any way in Glade to allow you to setup two LABELLED_BY relationships for a component. So what I did was setup a single LABELLED_BY relation for the spin buttons (to the label to the left of the spin button), and two LABEL_FOR relationships to the spin button (from the labels on each side of the spin button). This seems to nicely fix the problem although it doesn't speak the right hand label when you have focus on the spin button in question. Personally I think that's a good thing, but if we want that second ("units") label spoken, then I'm going to need to dig deeper. Please test. If we are happy with this, then I'll work out an equivalent patch for the gnome-2-20 branch.
This works for me. I didn't see a way to set up two LABELLED_BY's in the Glade interface designer, but it seems that you can tack them on manually. But then what is spoken is: First/real label units spin button That's no good -- and seems like it might take some doing to cause us to get: First/real label spin button units Therefore, my vote is for the current patch as it stands.
We talked about this bug in the Orca team meeting today. The plan is as follows: 1/ For GNOME 2.20, hand edit the opca-setup.glade file and just add in the new <atkrelation> clauses that are the equivalent of those found in the attachment in comment #7 (without the other bits that Glade seems to have touched). Patch to follow. 2/ For post-GNOME-2.20, open up a new RFE that will nicely allow up to speak/braille both labels for each of these spin buttons (multiple LABELLED_BY and LABEL_FOR relationships). Bug number to follow.
New RFE for the problem in 2/ in comment #9 is bug #473699.
Created attachment 94957 [details] [review] Hand edited patch for gnome-2-20 branch.
Created attachment 94958 [details] [review] Revised hand edited patch for SVN trunk.
I'ver attached two revised patches (one for gnome-2-20 branch and the other for trunk). I didn't like the other changes that Glade was making so I've removed them. I've also committed both these patches and moved the bug to a "[pending]" state. Please test and let me know if you find any problems. As noted above, further work on this (for post GNOME 2.20) will be done in bug #473699.
This seems to be working as expected.