GNOME Bugzilla – Bug 63480
scrolled window keyboard scrolling
Last modified: 2015-05-11 10:22:21 UTC
If no widgets in a scrolled window are focusable, the scrolled window should take focus to allow cursor key scrolling
Interesting question is how to indicate the focus - it's not the same as focusing a scrollbar since you need to scroll both horizontall and verticlaly. Also, what key binding for page left-right for the horizontal scrollbar (if you need to do that?) If somone was looking at this, they might also want to look at keybindings that should work when children of the scrolled window have focus; I think in Windows there are bindings (ctrl-arrows?) to scroll the window in similar cases. Putting this on 2.0.0, but I suspect it will be moved to a future milestone when we review 2.0.0 for puntage.
Adding GNOME2 keyword to all keynav bugs per sander's request. You can filter on the phrase 'luis doing GNOME2 work' to catch all instances of this so that you can ignore them.
See http://mail.gnome.org/archives/gtk-devel-list/2002-February/msg00104.html For patch and discussion. Fri Feb 15 20:09:45 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkscrolledwindow.[ch] gtk/gtkmarshallers.list: Add key bindings on GtkScrolledWindow for arrow keys, PageUp/PageDown Home/End to scroll the window. Bind Control-[Shift]-Tab to focus out of the scrolled window entirely. Allow the scrolled window to be focused if no child can be focused. (#63480) Fixes most of this. Remaining issues are: - Drawing of focus indication if the scrolled window itself is focused. - Should Home/End be left-right or top-bottom. (Control-Home/End takes the other.)
Tue Feb 26 19:38:14 2002 Owen Taylor <otaylor@redhat.com> * gtk/gtkscrolledwindow.c (gtk_scrolled_window_class_init): Switch control-home/end and home/end with the idea that scrolled windows more typically contain vertical sets of controls and to correspond to the bindings in GtkTreeView. Leave focus indication as a future fix.
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
*** Bug 91257 has been marked as a duplicate of this bug. ***
Move various non-critical bugs onto 2.2.1 milestone.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Do not know if it's proper to append my problems into this bug, My question is, why gtkscrolledwindow need Control+PageUp/Down to PageUp/Down? Can we remove it? In evolution, there is a case that a gtkscrolledwindow is contained in a GtkNotebook. And the control+pageup/down is conflicted. In the notebook, C+PageUp/Down is used to switch tab. But in the scrolledwindow, it is used to scroll page up/down. Thus if focus is in the scrolledwindow, control+pageup fail to switch to next tab.
You're right, Ctrl-PgUp quite often conflicts with controls in notebooks. However, to resolve this, Ctrl-Alt-PgUp/PgDn was added to GtkNotebook as an alternative for switching tabs. See bug #97860.
*** Bug 153968 has been marked as a duplicate of this bug. ***
Well, Bug 153968 is not quite a doublicate. Even if there is a focusable widget within the GtkScrolledWindow, I'd like to have the possibility to draw a focus anyway.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
10 years of no activity, closing