GNOME Bugzilla – Bug 500679
Shift left/right on a focuable label does not generate an ""object:text-caret-moved" event.
Last modified: 2007-12-12 07:43:27 UTC
See also Orca bug #486912 which is affected by this problem. Steps to reproduce: 1/ Start latest Orca. 2/ Run the "Dialog and message boxes" demo of gtk-demo 3/ Bring up the "Message Dialog" window. 4/ Tab to the "This message box has been popped up the following number of times:" label. 5/ Press the Home key to get to the beginning of the currently selected text. 6/ Move around (and select) characters with Shift-Left and/or Shift-Right. My evaluation from comment #4 of bug #486912: ...If you Shift-Left or Shift-Right along the label, it doesn't speak or braille anything. If this was a text object, we would be getting "object:text-caret-moved" events. For the label, we are just getting "object:text-selection-changed"
I am not sure where the cursor is during the text is being selected. Because when the text is selected, if press Left, the cursor will jump to the position before the first selected character; if press Right, the cursor will jump to the position after the last selected character. gail always treat the position before the first character is the cursor. Why doesn't Orca speak the text when there is "object:text-selection-changed"?
(In reply to comment #1) > I am not sure where the cursor is during the text is being selected. Because > when the text is selected, if press Left, the cursor will jump to the position > before the first selected character; if press Right, the cursor will jump to > the position after the last selected character. gail always treat the position > before the first character is the cursor. > > Why doesn't Orca speak the text when there is "object:text-selection-changed"? Orca could potentially do this. I believe we currently don't do so because we need to avoid duplicate output as a result of two interesting events for the same operation. For example, when working with an editable text area, we will see both object:text-selection-changed and object:text-caret-moved events when selecting text. By handling things as a result of listening for just one of these (e.g., object:text-caret-moved), we can be somewhat stateless and only output information once. If handled both kinds of events, we'd need to be more stateful and complicated. The strange thing is that normal editable text areas give us both types of events when we select text, but labels do not. For example, try the "Entry 1" text area in the gtk-demo case described in the bug opener. I'd expect labels to act just about the same way, except for the fact that the user cannot edit them.
Ah, gaillabel and gailentry handle the selection in different ways. I guess they are written by different people or at different time :) I think your suggestion make sense since we are getting "cursor-position" notify from the widget. BTW, gtklabel and gtkentry work different here too. When press shift+left, we get "cursor-position" and "selection-bound" from gtklabel but "cursor-position" and "scroll-offset" from gtkentry. But things work fine because we only listen "cursor-position" in gaillabel.
Created attachment 100750 [details] [review] patch
Li - I just tried the patch using the dialog and message boxes demo. It seems to work great! Thanks!
Great! Then I'd like to close the bug.