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 619486 - Orca does not give feedback when performing an incremental find in eclipse
Orca does not give feedback when performing an incremental find in eclipse
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: speech
2.30.x
Other All
: Normal normal
: 2.32.0
Assigned To: Jose Vilmar Estacio de Souza
Orca Maintainers
Depends on:
Blocks: 575776
 
 
Reported: 2010-05-24 08:00 UTC by Jose Vilmar Estacio de Souza
Modified: 2010-09-20 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
revision 1 (3.36 KB, patch)
2010-05-24 09:23 UTC, Jose Vilmar Estacio de Souza
reviewed Details | Review
revision 2 (3.83 KB, patch)
2010-05-25 05:07 UTC, Jose Vilmar Estacio de Souza
none Details | Review

Description Jose Vilmar Estacio de Souza 2010-05-24 08:00:34 UTC
Eclipse has a feature called incremental find in which the user types part of a text and Eclipse jumps to first line where the text exists. 
The find runs as the user types the text but Orca currently provides no feedback as the user types
Since Eclipse jumps to the line where the text was found, it is interesting that the orca read that line.
Comment 1 Jose Vilmar Estacio de Souza 2010-05-24 09:23:26 UTC
Created attachment 161839 [details] [review]
revision 1
Comment 2 Joanmarie Diggs (IRC: joanie) 2010-05-24 14:55:23 UTC
Comment on attachment 161839 [details] [review]
revision 1

Interesting. If I'm reading what you're saying correctly, this problem isn't as big of a problem as it looked to me when you asked about it on the list. Nice work, José!

Question: What happens if instead of typing, the user:

* copied and pasted text
* did a select all
* cut several lines of text and then did an undo
* did anything else to move the caret more than 1 offset

?

Nits:

* The purpose of script_utilites.py is to contain methods needed to find objects, compare objects, manipulate strings, etc., etc. The scripts themselves should deal with processing and reacting to events, including storing whatever data is needed for that purpose. Thus your movement keys should be in script.py (in __init__()); not in script_utilities.py.

* Within a list, you don't need a '\' to continue onto the next line.

* Please ensure that your lines are no more than 80 characters long -- that goes for comments as well as code -- and do not contain trailing whitespace.

If you fix the above, don't have any issues with tasks like copying and pasting, and have tested all of the functionality you've already implemented in this script to be sure it continues to work when navigating, when typing (including with various key echoes), when debugging, and when doing an incremental find, I'll commit your changes.
Comment 3 Jose Vilmar Estacio de Souza 2010-05-25 05:07:21 UTC
Created attachment 161907 [details] [review]
revision 2

I'll test tomorrow on my job
Comment 4 Jose Vilmar Estacio de Souza 2010-05-25 05:36:19 UTC
(In reply to comment #2)
> 
> Question: What happens if instead of typing, the user:
> 
> * copied and pasted tex
an object:text-changed:insert and an object:text-caret-moved are received by orca. 
The text inserted is spoken in the function onTextInserted and the new line to where the cursor was, is spoken in the function _presentTextAtNewCaretPosition.
My new patch attempts to prevent the function _presentTextAtNewCaretPosition is processed when a text is inserted.

> * did a select all
> * cut several lines of text and then did an undo
After the cut orca speaks the new line in which the cursor is positioned.
After the undo the new text is spoken.
> * did anything else to move the caret more than 1 offset
If the caret is moved with up/down/home/end/etc, no problems because it is processed in the default script.
I'll do more tests on my job and I'll report the results.
Time to sleep!
Thanks.
Comment 5 Jose Vilmar Estacio de Souza 2010-05-25 23:14:29 UTC
(In reply to comment #3)
> Created an attachment (id=161907) [details] [review]
> revision 2
> 
> I'll test tomorrow on my job
I used the eclipse for most of the day without any problem.
I found more problems, but not because of the patch.
Comment 6 Joanmarie Diggs (IRC: joanie) 2010-05-26 00:10:39 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > Created an attachment (id=161907) [details] [review] [details] [review]
> > revision 2
> > 
> > I'll test tomorrow on my job
> I used the eclipse for most of the day without any problem.
> I found more problems, but not because of the patch.

So is this patch ready to commit?
Comment 7 Jose Vilmar Estacio de Souza 2010-05-26 02:37:17 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #3)
> > > Created an attachment (id=161907) [details] [review] [details] [review] [details] [review]
> > > revision 2
> > > 
> > > I'll test tomorrow on my job
> > I used the eclipse for most of the day without any problem.
> > I found more problems, but not because of the patch.
> 
> So is this patch ready to commit?
Yes.
Sorry, I forgot to say that it is ready to commit.
Thanks.
Comment 8 Joanmarie Diggs (IRC: joanie) 2010-05-26 03:08:15 UTC
No worries. I just wanted to be sure. Committed to master.
http://git.gnome.org/browse/orca/commit/?id=dd4d2c632972cc2cd70b4391f2599f4668720296

If the incremental find issue has been completely addressed, feel free to close out this bug as FIXED.

Thanks!