GNOME Bugzilla – Bug 464468
Automatically scroll text caret to make it visible.
Last modified: 2008-06-10 05:42:57 UTC
This request enhancement came out of discussing potential solutions to Orca bug #463223. Orca, the GNOME screen reader has a "say all" function whereby a blind or low vision user can speak/braille the whole of a text document. As we progress through the document, what we would like to do for low vision users is to update the position of the text caret to continually show the position of what's being spoken. The problem here is that when we get beyond the visible text in the window, setting the text caret to the new hidden position is not automatically scrolling that line to make it visible. Note that Firefox and OOo Writer do not have this problem and nicel show the new (previous hidden) text caret location. Would it be possible to modify the Gtk+ text widget(s) to automatically scroll the text caret to a visible position if the caret is moved to a previously hidden location? Thanks.
For labels, this is a dup of bug 79216.
Eek! That's been open for over five years. Guess I shouldn't hope for too much then...
Matthias, is this really a dup? I think we're looking at what takes place in GtkTextBuffers when gtk_text_buffer_place_cursor() -- and I assume gtk_text_buffer_move_mark() -- is used. Currently you can programmatically place the cursor at a location that is not on the screen. Were this to be detected, couldn't gtk_text_view_scroll_to_iter() -- or gtk_text_view_scroll_to_mark ()(??) -- be called to do the scrolling? Looking at this comment: http://bugzilla.gnome.org/show_bug.cgi?id=79216#c2 > Would be nice, but quite hard to fix since the label knows > nothing about scrolling. The label would have to hunt up > the heirarchy for a scrolled window. GtkTextViews know about scrolling, so I think it's a different issue.
(In reply to comment #3) > Matthias, is this really a dup? I'm not sure how to interpret Matthias' comment, but my interpretation is that it might be a duplicate for labels, but it's also a new bug for editable text areas. Matthias, is that correct? Being able to solve this problem in GTK+ would be awesome and useful.
(In reply to comment #4) > (In reply to comment #3) > > Matthias, is this really a dup? > > I'm not sure how to interpret Matthias' comment, but my interpretation is that > it might be a duplicate for labels, but it's also a new bug for editable text > areas. Matthias, is that correct? > > Being able to solve this problem in GTK+ would be awesome and useful. > Mattias, a gentle nudge. :-)
This should not be very hard to do, since as you point out, entries and text views already have all the mechanism in place to do it. For text views, scroll_to_iter/scroll_to_mark should indeed allow you to do what you want. I don't think this can be handled 'inside gtk', necessarily. At least, we can not unconditionally force the text cursor to never leave the visible range. It would have to be driven by the AT (which already sets the cursor position, as far as I understand the above discussion). I guess simply calling gtk_text_view_place_cursor_onscreen after each cursor move might be sufficient.
Thanks! I've unblocked bug #463223 and I'll try your suggestion.
Unfortunately we can't call gtk_text_view_place_cursor_onscreen() from the AT side of the house. See Will's comment to bug #463223: http://bugzilla.gnome.org/show_bug.cgi?id=463223#c17
From http://bugzilla.gnome.org/show_bug.cgi?id=463223#c21, move the bug to gail.
Created attachment 112196 [details] [review] patch I made a patch. I try to test it, open gedit with a text file, make sure some of the text is out of screen. Press "Add" button and Orca starts to read the text. But seems gail_text_view_set_caret_offset is not called before the finish of the reading. What is the logic here in Orca?
Created attachment 112198 [details] [review] new patch Just found gtk_text_view_place_cursor_onscreen moves the cursor instead of scrolling...
Li, I've added an Orca patch (needed to test this) and a comment on that testing, to bug #463223 http://bugzilla.gnome.org/show_bug.cgi?id=463223#c22 Hopefully you have enough there to work out what needs to be done. Thanks.
Thanks. I tried that patch with http://bugzilla.gnome.org/show_bug.cgi?id=464468#c11, seems works fine. Please refer to http://bugzilla.gnome.org/show_bug.cgi?id=463223#c26
Thanks Li. Well, it's not working for me. Will, Joanie; if you get a spare moment, could you give these two patches a try: Gail patch: http://bugzilla.gnome.org/attachment.cgi?id=112198 Orca patch: http://bugzilla.gnome.org/attachment.cgi?id=112218 and then follow the gtk-demo test instructions in http://bugzilla.gnome.org/show_bug.cgi?id=463223#c22 Thanks.
It works for me as expected on my Hardy box (i.e. the text keeps scrolling up, one line at a time).
It now works for me. See: http://bugzilla.gnome.org/show_bug.cgi?id=463223#c29 Li, I think your change is good for checking in. Sorry for the false alarm. I've no idea why it didn't work for me the first time. Will, I'm removing your name from this bug. I don't think you need to try it as well. Thanks.
Thanks. 2008-06-10 Li Yuan <li.yuan@sun.com> * gailtextview.c: (gail_text_view_set_caret_offset): Automatically scroll text caret to make it visible, when AT sets its offset.