GNOME Bugzilla – Bug 562834
Can no longer configure keyboard shortcuts for switching tabs in gnome-terminal-2.24
Last modified: 2009-02-06 20:15:29 UTC
This is a follow-up to Bug 548600, which was marked fixed without any fix actually being there in GNOME-2.24. gnome-terminal-2.24 loses completely the capability to configure "Switch to Tab <n>" keybindings, and no distribution likes that (all are patching). I'm attaching patches to restore this in gnome-2-24 branch, together with translations. There is already one release-team approval from Matthias Clasen to put this in 2.24 (so it can be in 2.24.3 and we can drop the patches), so the maintainers just need a second, and also approvals from the i18n guys (or whereever is necessary) to just fix this finally.
Created attachment 123725 [details] [review] Patch to restore keybindings in gconf schemas and keybindings dialog UI This is basically svn diff -r3169:3171 from trunk, iirc
Created attachment 123726 [details] [review] Patch to restore translations from gnome-2-22 branch for gconf schemas and keybindings UI
(In reply to comment #0) > This is a follow-up to Bug 548600, which was marked fixed without any fix > actually being there in GNOME-2.24. It was marked FIXED because it *IS* fixed, on trunk. There was no promise made of a fix to 2-24. Since 2.24.2 is already done and gone, I don't think this is the time to do any non-critical changes to 2-24 branch.
Common users still can not configure keyboard shortcuts with vanilla gnome-terminal until 4 months from now when a 2.26.0 is released. Releases can be done outside the full GNOME tarball dates too. Many think this feature is critical and should have never been dropped in the first place, I provide a full patch that includes everything that should make i18n happy, which was the real blocker in the end of why this was backed out in 2.24.1.1. It's up for the maintainers to accept it or tell all the distributions that include a form of patches reintroducing this feature (Gentoo, Fedora 10, Ubuntu, to name a few), your primary consumers, to go and keep on patching this stuff in (currently all besides Gentoo without translations) and not give that to the distros that don't have the manpower to patch this back in or even track it. Three big distributions I checked are patching this, this should be a clear sign it is worth the trouble to do the mailing for the freeze request and get done with it. I did the hard part (2 hours of translation forward porting), I don't have the authority to do the maintainers job of freeze break requests that will very likely be granted.
+#define ACTION_VERB_FORMAT ACTION_VERB_FORMAT_PREFIX "%u" This needs to be "%x".
I see, that was bug 556893, which got into this patch because I made it from the trunk commit, which had it as %x. I was wondering why it changed to %x compared to Ubuntu's patch (which I think had %u at one point).. I'll update patch tomorrow.
Created attachment 124283 [details] [review] Updated patch to include fix for bug 556893
Hey, and what's that supposed to do? { tabs_entries, G_N_ELEMENTS (tabs_entries), N_("Tabs") }, - { help_entries, G_N_ELEMENTS (help_entries), N_("Help") } + { help_entries, G_N_ELEMENTS (help_entries), N_("Help") }, };
(In reply to comment #8) > Hey, and what's that supposed to do? > > { tabs_entries, G_N_ELEMENTS (tabs_entries), N_("Tabs") }, > - { help_entries, G_N_ELEMENTS (help_entries), N_("Help") } > + { help_entries, G_N_ELEMENTS (help_entries), N_("Help") }, > }; > The extra comma makes absolutely no difference on any reasonable compiler. The patch is made with diffing some bits between current and the trunk version at the time, and trunk has the last entry in that struct ending with a comma - it temporarily had an extra entry there, so the comma was required, later when the extra entry was removed the comma wasn't. So this got into this patch too, bringing it to trunk state. You can safely remove that small hunk from the patch. As for the extra comma or not - as I said, it makes no practical difference. Some maintainers prefer to have a leading comma, because it's easier to append new entries to it, some like to not have it for reasons I don't understand (probably something related to strict correctness when thinking about it in some certain way). I respect both sides (belonging to both camps, depending on how often a struct gets new entries), and it doesn't matter.
There's not going to be another 2.24.x release, and this is fixed on trunk. -> OBSOLETE.