? Using 2.23.91-svn here and the option is available:

Menubar -> Edit -> Keyboard Shortcuts -> Tabs -> Switch to {Next,Previous} Tab

and this are the two gconf keys you're looking for:

/apps/gnome-terminal/keybindings/next_tab
/apps/gnome-terminal/keybindings/prev_tab

closing. not a bug.

No, you misunderstand. There are keys bound by default to switch between the first through ninth tabs, which are alt+0-9. g-t used to have an option in keyboard shortcuts to configure these but I can no longer see it. I always change these as the defaults conflict with irssi, but can no longer.

I'm confirming this bug. This functionality used to be provided by options in the keyboard shortcuts configuration window (with the back-end gconf options of /apps/gnome-terminal/keybindings/switch_to_tab_1 being set to a value of "disabled"), and interferes with standard irssi keybindings (alt-2 to switch to window 2, etc).

I'm throwing another vote in for: PLEASE restore this functionality / ability to configure this behavior. Thanks!

Ok, I poked around in the code a bit, and I've come up with a pretty easy solution that would at least accomplish what *I* want. In terminal-tabs-menu.c:488, wrap the tab_set_action_accelerator(...) call in an if() check for a new configuration option "Disable 'switch to tab' keybindings". This should prevent the accelerator from being set, and from being listed in the Tabs menu.

I unfortunately am not familiar with the project (or gtk) to know exactly what needs to be done to add this gconf option (and have it display in the keybindings editor), but hopefully this should be pretty easy for one of you familiar with these things to add.

OK. I thought you mean just switching tabs, not switching to an explicit tab. however I'll have a look at this issue.

I believe an acceptable way to fix this bug would be to simply restore the exact UI and behaviour which was present before - individual keybindings for "Switch to tab 1", "... 2", etc. up to 10.

The ability to redefine the keybindings is crucial, especially for hotly contended ones like <A modifier>+<A number> being used as a switcher mechanism.

I'm afraid I met irssi first, so it has firmly taken ownership of Alt+<number> in my brain and fingers, so I find it absolutely necessary to be able to shift gnome-terminal to use Ctrl+<number> instead.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

Make sure you install the new gconf schemas, or else the tabs switching bindings will be non-functional.

I don't think this bug can be considered FIXED. Configuration can only be done in gconf-editor now, unlike before, and that is really suboptial - requiring writing strings instead of just hitting the desired key together with the modifiers not having descriptions about that available in the schemas - presumably due to string freeze, but translations are available in 2.22 branch if the english version is kept and OKed from releng/l18n teams.

For all intents and purposes for most users the feature has still gone away. And those that had configured it before, will find themselves stuck if they want to get back to defaults or something better than before, because the old configuration has effect via gconf, but the UI is gone.

Mart,

The UI is still there as far as I can see - http://orangesquash.org.uk/~laney/g-t.png

Unlees I'm misunderstanding you?

Iain

@Mart: Please do not reopen bugs without cause. This bug IS fixed. However the UI is only added back on svn trunk, since 2-24 is string frozen and thus that part cannot be committed there.

Yes it can if permission is requested and granted, and there is a very good case to get that permission from the relevant teams - I already suggested that in comment #8. One can even get most of the strings translated at first based on translations on the gnome-2-22 branch. This is a regression from 2.22 that should have never happened.
The cause of opening the bug I already told also in comment #8, I don't know what else to tell if you refuse to address them.

The configurability may be fixed, but as a result of this change, the *default* changed between 2.24.0 and 2.24.1 (unless I'm missing something). That's not really a good experience to push on users.

I'm pretty sure that if someone presented a patch to reinstate the ui with the translations from the 2.22 branch, nobody would object to it. 

Heck, I'll even grant you the first release team approval right here. But I don't have the time to work on digging out the translations myself.

(In reply to comment #12)
> The configurability may be fixed, but as a result of this change, the *default*
> changed between 2.24.0 and 2.24.1 (unless I'm missing something).
What do you mean? The default in the gconf schema is Alt+number, and the code in 2.24.0 also used Alt+number.

Upon upgrading from 2.24.0 to 2.24.1, in Fedora, Alt-<number> no longer works (no other changes made.)

That sounds like the updated schemas aren't installed. When the schema is installed correctly, you should get this:

$ gconftool-2  -R /apps/gnome-terminal/keybindings | grep switch_to_tab_
 switch_to_tab_1 = <Alt>1
 switch_to_tab_2 = <Alt>2
 switch_to_tab_3 = <Alt>3
 switch_to_tab_4 = <Alt>4
 switch_to_tab_5 = <Alt>5
 switch_to_tab_6 = <Alt>6
 switch_to_tab_7 = <Alt>7
 switch_to_tab_8 = <Alt>8
 switch_to_tab_9 = <Alt>9
 switch_to_tab_10 = (aucune valeur définie)
 switch_to_tab_11 = (aucune valeur définie)
 switch_to_tab_12 = (aucune valeur définie)

--
The patch is http://svn.gnome.org/viewvc/gnome-terminal?view=revision&
revision=3171 and only the change to terminal-accels.c is required for the UI.

Doesn't appear to be getting registered because of a
 'You must have at least one <locale> entry in a <schema>'
error, as 2.24.1 doesn't appear to have changeset 3171.

Sorry about the regression in 2.24.1.
I backed the partial patch out of the gnome-2-24 branch and released 2.24.1.1.

I have filed Bug 562834 for fully restoring this functionality on top of gnome-terminal-2.24.2, including translations of the gconf schemas and keybindings UI.