GNOME Bugzilla – Bug 402192
Orca does not speak text that is pasted in by middle mouse click.
Last modified: 2007-03-27 15:41:20 UTC
Steps to reproduce: 1. In Gedit or OOo Writer, select some text using the keyboard or the mouse. 2. Move to a different location within the document and click the middle mouse button. Results: The selected text is pasted into the new location, but Orca does not speak the newly-inserted text. Desired results: Orca would speak the newly-inserted text as it does when text is pasted using Control V. Additional information: As Will suggested in bug #400766: > The fix might be as simple as adding and else clause > that says "so...the last event wasn't a keyboard event, > eh? Well...if it was a mouse button 2 event, then speak > the inserted text." Or something like that.
> The fix might be as simple as adding and else clause > that says "so...the last event wasn't a keyboard event, > eh? Well...if it was a mouse button 2 event, then speak > the inserted text." Or something like that. So my question (before I start looking at this) is whether we just want to do this in the gedit and StarOffice scripts, or whether it's something that should be "mainstream Orca". Will, if it's the latter, where do you think it should go?
You know, I actually started looking at it and got it mostly working. But I wasn't happy with Orca's new behavior and got distracted by more interesting things with better outcomes. Issues: 1. Something is up with OOo as the "mainstream Orca fix" didn't work there. Need to investigate that further. 2. The end result, to me, was not always ideal due to other events that cause the same text to be spoken. For instance, if the text remained selected and we got (another) event to that effect, we'd speak the text because it was inserted, then we'd speak the text because it was selected. Or we might get a caret moved event for the line with the newly-pasted text and speak it again. This is app specific, of course. I spoke with Mike briefly about the possibility of adding some context to what was being spoken (e.g. "'blah blah blah' inserted) to help the user take it all in better, but he did not think that was a good idea. I'll let him elaborate on that. Given that the degree and cause of chattiness seemed to vary based on the app being used, and that we presumably(?) want this feature throughout Orca, what about putting it in "mainstream Orca" but then overriding it in the scripts where the default behavior grates on one's nerves? :-) I'll put this issue back on my plate (unless you're volunteering for it Rich ;-) ) and post a patch later today/tomorrow.
Created attachment 82480 [details] [review] first pass Funny how time gets away from you and it becomes "tomorrow." This seems to work as expected in gedit, evolution, and gnome-terminal. I tried it in gaim as well, but the middle-mouse-paste doesn't seem to be a feature there. This does not always work so well in Thunderbird. When Orca speaks what was pasted, it only does so partially (e.g. "whatever" was pasted, "tever" was spoken). This does not work at all in OOo Writer. Nothing bad happens; simply nothing gets spoken. I'm not sure why as StarOffice.py doesn't have its own onTextInserted(), and according to at-poke we are getting that event along with a MouseButtonEvent for button 2. I will investigate this some more, but since I promised to post a patch.... :-)
Hi Joanie. Thanks for the patch. I'll use that as a starting point and continue to look at the problem.
Is there anything I should be testing here? The speech and raille user doesn't normally ever use any mouse buttons for cutting and pasting.
Nothing at the moment Mike. Let me tweak Joanie's patch to see if we can get it working with OOo and then you can have at it. Note that this isn't something we are planning for GNOME 2.18. It would be nice though to attach a patch ready for commitment to the Orca code base after we branch for 2.19.
Created attachment 82507 [details] [review] revised patch to add in support for OOo Here's the deal with OOo: In default.py's onTextInserted, we're never getting to the point where we can check if we have a middle-mouse-click. Instead, we're returning here: # Ignore text insertions from non-focused objects, unless the # currently focused object is the parent of the object from which # text was inserted. # if (event.source != orca_state.locusOfFocus) \ and (event.source.parent != orca_state.locusOfFocus): return because event.source is the paragraph where the text was inserted; locusOfFocus is the selected text. In gedit, et al. text is not contained in individual paragraph objects so we don't run into this problem. Rather than add a "special case" to default.py, this patch just adds handling to StarOffice.py. Thoughts?
This approach is fine. We do similar things in several of the scripts. All, Joanie is "taking this bug back". I'm going to work on another one. Mike, could you give this a try and see if it works as you expect please? As mentioned above, I don't feel we need to push to try to get this into 2.18. It'll be a great addition when the source tree opens for 2.19. Thanks.
Thanks Rich. So taken. :-) Mike: Given the nature of this beast, some time tomorrow I will write up a few "real-life" examples of what gets said when that illustrate: 1. When things are working as one would expect (i.e. you get the same speech you'd get had you instead pasted with Control V) 2. When things are chattier than one (okay, than I) would expect. I think that will be easier than trying to paste via point and click non-visually. <smile>
Created attachment 84437 [details] [review] Revised patch to adjust for new line offset after the util.py refactor. I've committed this patch. It seems to work nicely. I'll put the bug into "[pending]" state for further review by others.
Closing as FIXED. If any problems are found, please reopen.