GNOME Bugzilla – Bug 138609
Next/prev TAB keybindings should not be passed through on first/last tab
Last modified: 2008-09-24 22:06:01 UTC
When I switch tabs with <Control>-<PgUp> and <Control>-<PgDown> and I reach the last tab, it will print 5~ on the terminal instead of doing nothing. This is Mandrake 10.0 with GNOME 2.6 with gnome-terminal 2.6
*** Bug 143291 has been marked as a duplicate of this bug. ***
Same on OpenBSD -current. This very annoying :(
Created attachment 29027 [details] [review] Don't produce garbage when trying to ctrl-pgup past last tab This patch restores the old behaviour for me. It isn't perfect - it still leaves the next/previous tab menu items active even when on the last/first tab, but I think this is a minor regression compared to dumping junk into the user's terminal session.
Note this is not really "dumping junk" but simply "dumping whatever the user is typing into the terminal"... Try hitting Ctrl-Page{Up,Down} in xterm.
This is fixed in 2.9, isn't it?
I still have to apply that patch in my package of 2.9.1: http://wwwra.informatik.uni-rostock.de/~waschk/Mandrake/GNOME2.9/
The patch basically makes it impossible to type Ctrl-PageUp/PageDown into a terminal. Does -no- terminal app need to geet those key combinations?
I don't see that this is a problem: an app that needs these keys (I don't know of any) wouldn't work properly when multiple tabs are active anyway. gnome-terminal already captures shift-pageup and control-shift-{t,c,v,n}, so this is merely a change in degree.
*** Bug 162860 has been marked as a duplicate of this bug. ***
*** Bug 147041 has been marked as a duplicate of this bug. ***
Bug 147041 was regarding the prev tab keybinding. These should both be handled in the same way. Updating summary.
*** Bug 152314 has been marked as a duplicate of this bug. ***
*** Bug 311294 has been marked as a duplicate of this bug. ***
Note that just trapping <Control>-<PgUp> and <Control>-<PgDown>, as mentioned by comments 5 through 8 above, is not sufficient since the keybindings can be changed. I, for one, don't use those bindings.
Now that I've looked more closely at the proposed patch, I see that my previous comment is not applicable. I was misunderstanding what was said. What I don't understand, however, is why we don't do "circular" tabbing like KDE's terminal. When you get to the last tab, and you do a "Next Tab", you go to the first tab. Likewise when you get to the first tab and do a "Previous Tab". Don't like that behaviour? Make it an option that can be turned off. This is definitely one of the features I missed when I switched from KDE to Gnome.
Bill Hayden: See discussion in bug 92139 for bug cycling. Basically comes down to accessibility reasons + want a more general preference that just gnome-terminal. It should work the same in *all* gnome apps; not just one. Maintainer doesn't want more prefs in g-t (this includes gconf).
That patch is not applicable as the menu items wouldn't have the right sensitivity anymore. I am more of the idea that the terminal should block those shortcuts (which can be changed in the Edit->Keyboard shortcuts dialogue) if there's more than one tab.
Created attachment 51382 [details] [review] gnome-terminal-dont-send-prev-next-keys-to-terminal.patch Don't pass the key presses for "Prev/Next tab" to the terminal itself, if there's more than one tab. We could potentially do the same thing for shortcuts to direct tabs. Also fixes a FIXME in the code now that we use a gtk+ > 2.2.
Hi Bastien, Overall the patch looks reasonable to me. Assuming it works, I would just commit it (after code freeze is over, of course). I don't think gnome-terminal has an active maintainer right now. A couple of nitpicks... + /* Capture the key presses */ + gtk_widget_add_events (GTK_WIDGET (window), GDK_KEY_PRESS_MASK); I think toplevel windows get key press events by default. + g_signal_connect (G_OBJECT(window), "key_press_event", + G_CALLBACK (key_press_callback), window); I believe key-press-event is more canonical than key_press_event.
Created attachment 51913 [details] [review] gnome-terminal-dont-send-prev-next-keys-to-terminal-2.patch Removed unneeded _add_events call, and use key-press-event instead of key_press_event (I think they're actually the same, but key-press-event would be what is specified in the new signal creation in gtk+).
Looks fine to me. It looks like Kjartan already did a 2.12 release for gnome-terminal, so I think that you should be able to just commit this. You might want to ask him though.
Committed to gnome-2-12 and HEAD. 2005-09-07 Bastien Nocera <hadess@hadess.net> * src/terminal-window.c: (terminal_window_init), (update_tab_sensitivity), (reset_and_clear_callback), (accel_event_key_match), (key_press_callback): Only send Previous tab/Next tab key events to the terminal if there's no tab, and not when we reach the boundary with multiple tabs (Closes: #138609)
This bug is still (or again) valid for 2.14.1.
Created attachment 63811 [details] [review] gnome-terminal-dont-send-prev-next-keys-to-terminal-3.patch Also remove Num-Lock from the modifiers.
*** Bug 329824 has been marked as a duplicate of this bug. ***
*** Bug 349475 has been marked as a duplicate of this bug. ***
Bastien, you made me smile :) I thought the behavior was really random, just to see that Num Lock changes it. I'd never thought of this. This hits many people, so let me be the one who asks: is there something wrong with the new tiny patch? If not, will it get commited?
As the patch is obviously correct and that it's been sitting there for 4 months, committed to HEAD and gnome-2-14 2006-08-05 Bastien Nocera <hadess@hadess.net> * src/terminal-window.c: (accel_event_key_match): Only send Previous tab/Next tab key events to the terminal if there's no tab, and not when we reach the boundary with multiple tabs, and ignore NumLock as well (Closes: #138609)
Somebody broke this, and it happens again with: gnome-terminal-2.23.91-1.fc10.i386 vte-0.17.3-1.fc10.i386
*** This bug has been marked as a duplicate of 453193 ***