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 464705 - Provide option to keep caret in center of magnifier region of interest
Provide option to keep caret in center of magnifier region of interest
Status: RESOLVED FIXED
Product: orca
Classification: Applications
Component: magnification
unspecified
Other All
: Normal enhancement
: 2.22.0
Assigned To: Rich Burridge
Orca Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-08-08 14:03 UTC by Willie Walker
Modified: 2008-07-22 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Revision #1 (66.48 KB, patch)
2007-12-07 16:49 UTC, Rich Burridge
committed Details | Review

Description Willie Walker 2007-08-08 14:03:26 UTC
From the Orca user list:

The "move the magnifier window the least" is OK for checkboxes, buttons, menus or the caret, although having focused items in the center of the magnifier window would help find them more easily. The problem is with editing text. For example, if you delete a long line of text using Del the cursor will eventually reach the right edge of the magnifier window and you can't see what you are deleting anymore. If you delete text using Backspace the cursor will reach the left edge of the magnifier and you can't see what you're deleting anymore. You can try this with any text editor. I think it is more natural to be able to see the area around your point of focus.
 
It would be great if you could add the option of keeping focus centered all the time (for cursor, caret, menus, buttons, menus, etc.)
Comment 1 Rich Burridge 2007-12-07 16:49:15 UTC
Created attachment 100541 [details] [review]
Revision #1

Thanks also to Joanie for her help and guidance on what was required here.
Comment 2 Joanmarie Diggs (IRC: joanie) 2007-12-07 17:07:58 UTC
I've tested this quite a bit and I think the users will find it helpful.

When Rich asked me about this, I suggested we not just implement what the summary specifies, namely the ability to keep the caret at the center, but to add a couple of other modifications directly related to the problem reported by the user:

1. The addition of an "edge margin".  The problem described by the user is that when the caret moves to the edge you can no longer see what you are about to delete (on the right) or backspace (on the left).  One solution is to center the caret, and that works for many users.  However, this can make the screen seem rather "jumpy".  And some users prefer the "push" type of alignment we currently have for caret tracking -- with the exception of the issue reported.  Now the user can specify a margin so that he/she can will always "be able to see the area around your point of focus" while still using the "push" alignment.  Edge margin applies to caret tracking only, and is expressed as a percentage ranging from 0 (equivalent of what we do now with push) to 50 (equivalent to centering, which was also implemented).

2. Separating out caret tracking from control tracking.  The user said, "It would be great if you could add the option of keeping focus centered all the time (for cursor, caret, menus, buttons, menus, etc.)".  Agreed.  However, an all-or-nothing centering setting is problematic for some users, again, because of the jumpiness.  Users might want centered controls but not centered text or vice versa.  Separating them accomplishes that.  And it also buys the user something else: The ability to turn tracking on or off as needed for controls separately from the caret.  A real-world example from my recent "itinerant" days:  There is some library cataloging software that, upon a single button press, populates a bunch of fields (given them each temporary focus in the process).  Screen magnification software goes nuts if control tracking is enabled.  Being able to turn off control tracking, but leave on mouse and caret tracking, was essential for the user to do her job effectively.
Comment 3 Rich Burridge 2007-12-07 21:01:05 UTC
Will has just phoned to say he likes the fix, so I've committed it
and put the bug into a "[pending]" state.
Comment 4 Mike Pedersen 2007-12-09 20:11:41 UTC
I'm probably not the best one to verify this one.
Comment 5 Joanmarie Diggs (IRC: joanie) 2007-12-09 20:19:16 UTC
I've hammered on it quite a bit.  So if no one objects, I'll verify it.  :-)

Rich I think this one is good to close.
Comment 6 Rich Burridge 2007-12-10 03:58:24 UTC
Okay. Thanks.