GNOME Bugzilla – Bug 87764
Of tabs, MDI and Window menus
Last modified: 2021-07-05 10:54:09 UTC
This issue came up in bug #87260, and is also related to bug #72101. Question basically is: what shortcuts should we use for switching between tabs that contain GtkTextViews. And in particular, for MDI apps where Ctrl+PgUp/PgDn (which currently switch to next/previous tab) aren't guaranteed to work because GtkTextView uses those keys for moving the cursor around. Some options I can think of: Option 1) Have "Alt+<n> = switch to nth tab" built into notebook control. Advantages: number always maps to position of tab on screen. Disadvantages: can only handle 10 tabs, although you're asking for trouble with that many tabs anyway. Alt+<n> may be used by window manager for something else (e.g. switching workspaces). In case of MDI, only works with tabbed MDI model, doesn't map well to running multiple instances of same application. Option 2) do what profterm and (soon) gedit do. On the Window menu, assign an Alt+<number> shortcut to each document. Disadvantages: can only handle 10 documents, Alt+<n> may be used by window manager for something else (e.g. switching workspaces). Only works with tabbed MDI model, doesn't map well to running multiple instances of same application. Numbers may not map to actual order of tabs on screen. Option 3) do what Windoze does: assign a mnemonic to each document on the menu: _Window _1. fred.txt _2. jo.txt _3. someother.txt . . _9. ninthdoc.txt --- _More > Advantage: can handle as many docs as you like, via submenus. Model works whether you're using tabbed MDI or multiple instances of the same program (in theory at least, dunno how easy in practice). Disadvantages: not as easy to press Alt+W, <number> than it is just to press Alt+<number>. Numbers may not map to actual order of tabs on screen. Option 4) Just remove the Ctrl+PgUp/PgDn functionality from GtkTextView, since it only scrolls the view left/right, which you can kind of do with Home/End anwyay. This would be an accessibility regression, though. HIG team ought to decide how we'd like to handle MDI, document this in HIG, and suggest changes to tab control if necessary.
A simple solution that can lead to closing many other bugs and prevent future bugs is to ban MDI. How does one convince a patient to focus on getting rid of the disease instead of the symptoms?
*** Bug 87260 has been marked as a duplicate of this bug. ***
I would be more than happy to ban MDI and say so in the HIG today... that won't change the fact that we already have GNOME 2 apps doing it, though. And even if we only support the multiple-instance model instead, it would still be nice to decide whether we allow switching between those instances via a menu item, if such a thing is technically feasible. Relying on Alt+Tab to do so is a pain in the butt in my experience. We also have a subset of the problem with any tabs that contain multi-line text fields, not just document-level tabs, so banning MDI doesn't really solve the problem.
Perhaps use the CUA standard? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F29AL000/2.2.54?SHELF=CEESL002&DT=19921204095534 (Figure 172) Page Up and Page Down do as they say. Ctrl switches them to horizontal scrolling. Alt is used for switching notebook pages.
The PgUp/Dn stuff already works as per the CUA spec AFAIK.... I don't see any reference there to Alt switching tabs, I assume this is a logical extension on your part :) Sure, that would work, and is probably something we ought to consider for the new notebook control when it arrives in gtk 2.4 or whenever... I doubt if Owen would accept any keynav U-turns before that though (although additions might be acceptable). (When we were writing the keynav proposal we just had to weigh up the pros and cons of rigidly following a particular existing spec, or being consistent with other toolkits. And unfortunately the other toolkits we were comparing against used Ctrl+PgUp/Dn to switch tabs...)
No extension. It's in the figure I mentioned. Link to figure in page: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F29AL000/2.2.54?SHELF=CEESL002&DT=19921204095534#FIGKAA
Absolutely right, my oversight. I was having a particularly bad day yesterday, it seems :)
OK couple of questions: Should we add ctrl+PageUp/PageDown should vertical scroll to the keynav spec (if it's not already) and if it is should we file gtk bugs about this. Is it appropriate to add alt+PageUp/PageDown to switch tabs in epiphany?
Regarding tabs, HIG should include recommended keybindings for: Open New Tab Tab Right Tab Left Close Current Tab Here's a survey of what different apps do by default: Mozilla: ctrl-t, ctrl-pgup, ctrl-pgdwn, ctrl-w Galeon 1&2: ctrl-t, ctrl-pgup, ctrl-pgdwn, ctrl-w Epiphany: ctrl-t, ctrl-pgup, ctrl-pgdwn, ctrl-w gnome-terminal: ctrl-shift-t, ctrl-pgup, ctrl-pgdwn, ctrl-shift-w gedit: ctrl-n, <none> <none> ctrl-w multi-gnome-terminal <none> shift-left, shift-right, <nothing> glimmer 1.2: ctrl-n, <none> <none> ctrl-w anjuta1: ctrl-n, <none> <none> ctrl-w gnumeric: <none>, ctrl-pgup, ctrl-pgdwn, <none> bluefish ctrl-n, F3, F4, ctrl-w Many of the above gnome apps violate HIG guidelines already, and many of the above keybindings are recommended for other uses in the HIG. I don't think it will be of much use filing bugs on them unless there is a consistent recommendation of what to do instead. (cf. http://developer.gnome.org/projects/gup/hig/1.0/userinput.html#shortcuts ) For giggles, over on the KDE side: Kate: ctrl-n, alt-left, alt-right, ctrl-w Konqueror: ctrl-shift-n, <none> <none> ctrl-w Konsole: alt-ctrl-n, shift-left, shift-right, none Requiring the same keybindings for everything may not be reasonable (ctrl-n versus ctrl-t), but please, can the madness stop?
re: > Regarding tabs, HIG should include recommended keybindings for: > Open New Tab > Tab Right > Tab Left > Close Current Tab I don't think we should have keybindings for close current tab. Instead i think we should have a single close menu entry (and no quit menu item) that closes the current tab only. Similarly i think the window border close button should only close the current tab as well. This prevents data loss from accidentally closing tabs you did not mean to, and is more generally closer to sdi behavior the hig encourages. regarding the other keybindings. There already exist cua keybindins for tab right/left we should use these. Ctrl+t is fine for new tab, though I feel that for the most part this only applies to web browsers and terminals. damn tabs, fix the wm :)
HIG maintainers, could you give a status update on this bug? Specifically, will Ctrl+PgUp/Ctrl+PgDn be the recommended shortcut key for switching tabs or not? It seems to be the defacto standard nowadays, and the Ctrl key and the PgUp/PgDn keys can be used with one hand only, whereas with Alt it requires two hands on most keyboards.
FWIW, Konqueror uses Ctrl+[ and Ctrl+] to switch tabs.
>Specifically, will Ctrl+PgUp/Ctrl+PgDn be the recommended shortcut key for >switching tabs or not? IMHO it would be a bad idea to recommend a shortcut that doesn't work in various situations :/ Ctrl+Alt+PgUp/PgDn is the only shortcut that currently always works; so it's probably either that or switch to something different and unfamiliar altogether.
It doesn't work in gnome-terminal but that's because it has special requirements, Ctrl+C/V for copy/paste doesn't work in gnome-terminal either. That makes gedit about the only real GNOME app that doesn't support it but the maintainers think this is the way it should be for applications with an edit area; see bug 160747 and bug 163494. Basically I believe the recommendation should be Ctrl+PgUp/PgDn, and if Joe Developer feels that an exception to the rule is warranted, at least make Ctrl+Alt+PgUp/PgDn work. FWIW, Ctrl+PgUp/PgDn also switches tabs in OOCalc.
Agreed. I think it's preferable to go with the defacto standard here, it's usually the one that works in most situations and is also most familiar to people. I usually don't really like the HIG being in the business of veering too far from what most applications designers are already doing versus stabilizing what we see as best practices in the wild. Not that we don't need to lay down the law when necessary... :) however most of our laws are simply writing down what's acceptable and already being done.
Bug 705648 is tracking the idea of changing the the shortcut in GtkTextView (option 4 from Calum's original report).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-devel-docs/-/issues/ Thank you for your understanding and your help.