GNOME Bugzilla – Bug 618589
when debugging in eclipse, sometimes orca reads the same line twice
Last modified: 2010-05-22 00:28:31 UTC
When a breakpoint is reached and it is in a different file of the current, the line containing the breakpoint is spoken twice. Analyzing the debug output generated by orca, I found two events that generate the same speech. vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv vvvvv PROCESS OBJECT EVENT object:state-changed:focused vvvvv vvvvv PROCESS OBJECT EVENT object:text-caret-moved vvvvv The same content is spoken in the first and third event butt the second event produces no output.
So, strictly guessing here without looking: The different file is issuing the state-changed:focused event (detail1 == 1) to say "hey, I have focus now." The second event, I suspect is detail1 == 0 (look in your debug.out to verify this). If so, it's probably from the current (or what used to be the current) file. It would be saying, "hey, I'm giving up focus to something else." The third event is because the caret in the different (now the new current) file has moved. Before, the default script got that caret-moved event, saw that the last key pressed wasn't a cursor related key, and ignored it. Now that you've added special handling for debugging, we are speaking the caret-moved event. And we're speaking the focused event. As a general rule, you really really don't want to ignore that focused event (detail1 == 1). So if it were me, and assuming all my guessing above is correct, I'd try to find a graceful way to identify to identify this particular case in your new script and prevent it from being presented. Pseudo-code wize, can you think of a way to describe how you might be able to tackle this problem? If so, I can help you with the Orca-specific stuff.
(In reply to comment #1) > So, strictly guessing here without looking: > > The different file is issuing the state-changed:focused event (detail1 == 1) to > say "hey, I have focus now." > Yes: OBJECT EVENT: object:state-changed:focused detail=(1,0,None) app.name='Eclipse' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' > The second event, I suspect is detail1 == 0 (look in your debug.out to verify > this). If so, it's probably from the current (or what used to be the current) > file. It would be saying, "hey, I'm giving up focus to something else." > OBJECT EVENT: object:state-changed:focused detail=(1,0,None) app.name='Eclipse' name='None' role='text' state='editable enabled focusable focused multi line sensitive showing visible' relations='' > The third event is because the caret in the different (now the new current) > file has moved. > Yes, I press the f7 key. > Before, the default script got that caret-moved event, saw that the last key > pressed wasn't a cursor related key, and ignored it. Now that you've added > special handling for debugging, we are speaking the caret-moved event. And > we're speaking the focused event. > > As a general rule, you really really don't want to ignore that focused event > (detail1 == 1). So if it were me, and assuming all my guessing above is > correct, I'd try to find a graceful way to identify to identify this particular > case in your new script and prevent it from being presented. > > Pseudo-code wize, can you think of a way to describe how you might be able to > tackle this problem? If so, I can help you with the Orca-specific stuff.
Assuming you didn't make a copy and paste mistake in your comment, both the object:state-changed:focused events have detail1 == 1. Interesting. Two back-to-back claims for being the object for focus. It would be interesting to know if those two objects are the same object (in which case we're getting a duplicate event and ignoring the second), or if they're different objects. In which case, who all is claiming focus and why?
Created attachment 161535 [details] [review] my first try to fix Try to fix this situation.
Review of attachment 161535 [details] [review]: Overall this looks good. But I'm wondering if you're doing more work than you need to be. It turns out that Orca stores a variety of things as a "pointOfReference". One of these is the lastCursorPosition which includes both the object and the offset. As a complete coincidence, I had occasion to use it last night to eliminate the presentation of duplicate caret-moved events being emitted by OOo Writer. I wonder if a similar approach will help you in Eclipse. What I did for the soffice script can be found here: http://git.gnome.org/browse/orca/commit/?id=483a070f15641962b1326868df5d4f869d3f8174
Created attachment 161598 [details] [review] Revision 2 a refactory based in http://git.gnome.org/browse/orca/commit/?id=483a070f15641962b1326868df5d4f869d3f8174
Review of attachment 161598 [details] [review]: This looks better. However, as was done with the soffice change, isDuplicateEvent() needs to be script_utilites.py; not script.py. Rationale: 1. Consistency is a a good thing; developers should not have to hunt around in order to figure out which *.py file a given script chose to put something. 2. The more important reason: While I've not made this change yet, I am very seriously considering turning over at least some of the duplicate-event identification to Orca's default script. (Or maybe even focus_tracking_presenter.py. I need to give it some more thought. But anyway....) The point is: there would be some cases in which the Utilities.isDuplicateEvent() would be called by the default script or focus_tracking_presenter. If you want things to behave as expected for Eclipse, your new method would need to be in the Utilities class; not the Script class. Make sense? If so.... If you'll make that change and test it, I'll push your fix into master.
Created attachment 161602 [details] [review] revision 3 Included script_utilities.py
Review of attachment 161602 [details] [review]: Sweet! Looks good to me. Committed to master. Note that you had three unused import lines in script_utilities.py (pytaspi, debug, and orca_state). So I went ahead and amended the commit to remove those. Hope you don't mind. Having done so, that file now pylints to a 10.0. Once you've verified the commit (and my tiny adjustment), please close this bug as FIXED. Thanks! And again, nice work! http://git.gnome.org/browse/orca/commit/?id=1424a9ea408cb71caed401491defa13c87648562
(In reply to comment #9) > Review of attachment 161602 [details] [review]: > > Sweet! Looks good to me. Committed to master. > > Note that you had three unused import lines in script_utilities.py (pytaspi, > debug, and orca_state). So I went ahead and amended the commit to remove those. > Hope you don't mind. Having done so, that file now pylints to a 10.0. > > Once you've verified the commit (and my tiny adjustment), please close this bug > as FIXED. Thanks! And again, nice work! > http://git.gnome.org/browse/orca/commit/?id=1424a9ea408cb71caed401491defa13c87648562 After apply the patch to master I found the following messages: Traceback (most recent call last):
+ Trace 222027
s.processObjectEvent(event)
self.listeners[key](event)
and (orca_state.lastNonModifierKeyEvent.event_string \
I have not received this error before, but I was testing in a separate branch. I do not know how to revert the commit, I could test without it.
That's a different, coincidental issue. I'll fix it in a different bug.
By the way, you don't want to apply anything. You just want to check out master.
Actually, I'm not even opening a different bug for it. It's a one-line sanity check in default.py. I just committed it to master: http://git.gnome.org/browse/orca/commit/?id=a70f7983b2fd23f87583f9394b558f5feced1811 Therefore, please pull master and test again. There are no patches to apply.
Hi Joanie, Thank you for your great help. Without it I would not have succeeded.