GNOME Bugzilla – Bug 92310
add info keyboard shortcuts
Last modified: 2018-05-22 12:37:51 UTC
The yelp info browser is very clean, but I believe reading an info manual would be faster if some info shortcuts were added, even if only n for next, p for previous, u for up, t for top. Perhaps they could also be used for other kinds of help files, where Previous, Contents and Next are very often seen. This would make it easy to browse a manual efficiently using only the keyboard.
Hmm .. it sounds like a great idea to me, though I have no idea how it would be implemented without making a TOC of info-pages before-hand (which from what I've heard is a pretty large task). I'll add the usability and Bill Haneman to the CC-line to hear if they have any opinions on this.
Well, it is kind of against the letter of the current HIG to have shortcuts that don't take a modifier, because you're more likely to activate them by accident. But I know GIMP and Evolution make heavy use of these sorts of shortcuts too, so I don't know how long the HIG will be able to maintain that position :)
Each node in an info document lists a "previous", "next" and "up" node. So you don't need to generate a toc. Also these are not really keyboard shortcuts. You're not supposed to be able to type into info documents (they are documentation). Info viewers are generally driven by the keyboard. It is like saying that the gnome games that are played from the keyboard are using keyboard shortcuts improperly. :)
True, I just can't help feeling they should be related to the existing HIG-recommended shortcuts for browser apps[1]: Up: Alt-Up Back: Alt-Left, so Previous = Shift-Alt-Left? Forward: Alt-Right, so Next = Shift-Alt-Right ? [1] which Yelp doesn't currently implement either *cough* :)
Metacity (I am talking about version 2.4.34) by default binds: /apps/metacity/window_keybindings/move_to_workspace_left Shift-Alt-Left /apps/metacity/window_keybindings/move_to_workspace_right Shift-Alt-Right So this would create some conflict with that.
If that's a conflict with an already-recommended keybinding (from the GNOME keynav proposals) then we should file a Metacity bug for that, at least to keep the discussion going. Certainly I think nobody should bind "Shift-foo" if "foo" is already being used for 'next/forward' type navigation, since Shift is the convention for reversing the direction of such navigation. BY that logic however, I think Shift is a poor choice of modifier to add to an existing 'forward/back' binding. IOW, if Alt-right is forward, should Alt-shift-right be 'back' ? Of course that seems silly since we have 'Alt-left', but it's reason enough to avoid using 'Alt-Shift-left'==Previous in this case, IMO. What about PgUp and PgDn? They would seem to make more sense to me, perhaps with modifiers added.
There's no conflict as things stand, the HIG only recommends the back/forward/up shortcuts (Alt-left/up/right) which don't clash with anything. But as Trevor points out, Metacity uses pretty much every other available combination of <mod>+left/right, so choosing obviously-related shortcuts for prev/next would be a problem. PgUp and PgDn, well, they scroll the page up and down :) And Ctrl+PgUp/PgDn scroll it left and right. So we can't really recommend those either. Alt+PgUp/PgDn could be a possibility though.
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 :)
Info pages are temporarily out with 2.6, but this regression will be addressed for 2.8. I just wanted to post a heads-up to anybody watching this bug that I currently have Alt+Up and Alt+Down working for DocBook documents for previous resp. next. I intend to use the same keybindings for any other format for which Yelp can actually figure a page structure.
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.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/yelp/issues/2.