GNOME Bugzilla – Bug 73423
GDK_ISO_Left_Tab
Last modified: 2014-03-22 17:55:23 UTC
The GTK keybinding setup relies on the assumption that <Shift>Tab produces the GDK_ISO_Left_Tab keysym. We enforce this for non-XKB by fudging the keymap that we get from X; for XKB, this setup is very commonly the case, but it's quite possible that it might not be the case on some systems, so we really should enforce it there too. Since fudging the keymap is harder for XKB, we probably need to simply special case it in: gdk_keymap_lookup_key () gdk_keymap_translate_keyboard_state () gdk_keymap_get_entries_for_keyval () gdk_keymap_get_entries_for_keycode ()
Moving non-critical and hard-to-fix bugs to 2.0.2
Move open bugs from milestones 2.0.[012] -- > 2.0.3, since 2.0.2 is already out.
Are there any keyboards that have a physical ISO_Left_Tab key? Or how would it be different from Tab with the Shift status bit set? I'm not an expert in X keymaps, so forgive me if this sounds like a dumb question.
I have no idea whether GDK_ISO_Left_Tab occurs on any keyboards; I'm sure its' not common The thing here is that to handle tab properly in the GTK+ key binding framework it needed to be consistent whether Shift-Tab gave GDK_ISO_Left_Tab or not. Since the most common platform for GTK+ (XFree86) set things up with Shift<Tab> giving ISO_Left_Tab, I picked this way. (GTK+ handles converting <shift>Tab to ISO_Left_Tab when matching key bindings, just as it converts <shift>a to A, so it's pretty much invisible to programmers.)
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
closing out old bugs