GNOME Bugzilla – Bug 147041
Hitting "Prev Tab" (Ctrl-PgUp) in gnome-terminal inserts escape codes if you're on the first tab
Last modified: 2005-01-03 22:14:33 UTC
Distribution: Debian testing/unstable Package: gnome-terminal Severity: normal Version: GNOME2.6.1 2.6.x Gnome-Distributor: Debian Synopsis: Hitting "Prev Tab" (Ctrl-PgUp) in gnome-terminal inserts escape codes if you're on the first tab Bugzilla-Product: gnome-terminal Bugzilla-Component: general Bugzilla-Version: 2.6.x Description: Description of Problem: I just installed a new gnome 2.6 system, replacing my dead 2.4. I noticed a bug in gnome-terminal: if you're already on the first tab, then hitting Ctrl-PgUp (which otherwise moves you to the previous tab) instead types the escape sequence "\e[5;5~". This didn't happen in 2.4. [The equivalent thing happens if you hit Ctrl-PgDn from the last tab.] Steps to reproduce the problem: 1. Open a gnome-terminal with only one tab. 2. Hit Ctrl-PgUp Actual Results: \e[5;5~ gets typed into the terminal. Expected Results: Nothing should happen. How often does this happen? Always Additional Information: Here's a little patch. The problem seems to be caused by the disabling of the Ctrl-PgUp accelerator when you're on the first tab, so the terminal gets the Ctrl-PgUp keypress. The patch is simply to not bother disabling the prev tab and next tab menu options; calling gtk_notebook_prev_page() when you're on the first page is a no-op already. You just don't get the greying-out of the "Prev Tab" menu option the way you used to. --- terminal-window.c.dist 2004-07-01 17:45:12.000000000 -0400 +++ terminal-window.c 2004-07-01 17:45:54.000000000 -0400 @@ -1283,8 +1283,14 @@ notebook = window->priv->notebook; page_num = gtk_notebook_get_current_page (GTK_NOTEBOOK (notebook)); + /* + * Keep the accelerator active, so as to prevent "\e[5;5~" from being + * typed when the user hits Ctrl-PgUp on the first tab. + */ + /* gtk_widget_set_sensitive (window->priv->previous_tab_menuitem, page_num > 0); + */ /* FIXME @@ -1299,8 +1305,13 @@ else gtk_widget_set_sensitive (window->priv->close_tab_menuitem, TRUE); + /* + * As above. + */ + /* gtk_widget_set_sensitive (window->priv->next_tab_menuitem, !on_last_page); + */ } static void ------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-07-09 10:59 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "gnome-terminal". Setting to default milestone for this product, '---' The original reporter of this bug does not have an account here. Reassigning to the person who moved it here, unknown@bugzilla.gnome.org. Previous reporter was linux@paip.net. Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
*** Bug 146560 has been marked as a duplicate of this bug. ***
Has a patch so I'm setting priority to high. However, please attach patches separately to bugzilla in the future, since putting them inline can cause their format to get screwed up.
It needs to be decided whether we want to have the menu item be sensitive in the edge cases but noop a.k.a. useless, which would be confusing and is rather bad ui IMHO, or insensitive but somehow eat the corresponding keyboard shortcuts. If the 2nd option is the good one, we probably need -not- to eat the shortcuts when there is just one tab in a window. The patch needs-work, then. Setting priority/urgence to saner levels.
Prev/Next tab handling on first/last tab should all work the same. Duping to the older 'Next tab' bug that also has a patch. *** This bug has been marked as a duplicate of 138609 ***