GNOME Bugzilla – Bug 510231
_presentTextAtNewCaretPosition() assumes standard navigation keys
Last modified: 2008-09-05 16:08:45 UTC
Steps to reproduce: 1. In OOo Writer, customize your navigation keystrokes to something non-standard (I made F4 move to the next paragraph and Shift+F3 move to the next line). 2. Create/open a document and navigate it using your new commands. Expected results: We'd braille and speak the new location. Actual results: We just braille it. I took a look at default.py's _presentTextAtNewCaretPosition() and found this comment: # Guess why the caret moved and say something appropriate. # [[[TODO: WDW - this motion assumes traditional GUI # navigation gestures. In an editor such as vi, line up and # down is done via other actions such as "i" or "j". We may # need to think about this a little harder.]]] # I'm filing this bug because I think we should think about this a little harder. :-)
*** Bug 515924 has been marked as a duplicate of this bug. ***
From Bug 515924, so we don't lose it: > Would it be possible to solve the field case, and the paragraph case, and the > vi case, and other cases for other apps we haven't even thought about by always > storing our last cursor position and basing our "guess" on our new position > relative to the old one? I think in many cases we can indeed infer what to speak based upon prior/current caret position alone. I think one of the cases we need to consider, however, is whether we speak the character, word, line, etc., if the caret moves from one line to the next.
First coarse pass at GNOME 2.24 planning.
Closing this one out. We *may* get to it as a refactoring exercise, but in reality, this is something we will most likely never do unless a user logs a specific bug for a specific application. I guess we could always make one up (e.g., use 'vi' in gnome-terminal), but I think we should wait for real user impact before doing this.