Bug 86403 - Shift+tab does not go back in fields in gtk2 dialogs
Summary: Shift+tab does not go back in fields in gtk2 dialogs
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gtk2
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Owen Taylor
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-21 13:49 UTC by Pierre Sarrazin
Modified: 2007-04-18 16:52 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-10 22:28:54 UTC
Embargoed:


Attachments (Terms of Use)

Description Pierre Sarrazin 2003-03-21 13:49:48 UTC
Description of problem:
The tab key moves from one field to another in a dialog,
but shift+tab does not go back, contrary to my expectations.

Version-Release number of selected component (if applicable):
gtk2-2.0.6-8
libgnomeui-2.0.3-3

How reproducible:
Every time.

Steps to Reproduce (for example):
1. Right-click on the panel
2. Add to Panel
3. Launcher...
4. Use tab to go from Name field to Generic name field.
5. Press shift+tab
    
Actual results:
The cursor stays in the Generic name field.

Expected results:
The cursor would go back to the Name field.

Additional info:
Ctrl+tab does not have a Ctrl+shift+tab equivalent either.

Comment 1 Owen Taylor 2003-03-21 14:12:35 UTC
This works in general.

What keyboard layout are you using? (the French-Canadian layout
is rather exotic when compared to other layouts, so it wouldn't
suprise me a lot if there was a problem with it in specific.)

Have you changed anything else about your keyboard configuration
(e.g., disabled XKB, created a .Xmodmap, etc.)

Is there anything else about your system that might be different
from a standard Red Hat 8 install?


Comment 2 Pierre Sarrazin 2003-03-22 01:00:14 UTC
> What keyboard layout are you using?

The 'qc-2' layout, but the 'qc' layout gives the same
result in the above scenario.

Interestingly, the 'us' layout gives a different but still
incorrect behavior: shift+tab goes to the next field,
just like tab alone.

The exact command that is used by the Keyboard Layout
Switcher Preferences applet to install the 'qc-2' layout
is 'gkb_xmmap qc-2'.  For the 'us' layout, it is
'gkb_xmmap us'.

Another data point: the 'us101' layout behaves like 'qc-2':
shift+tab does nothing.


> Is there anything else about your system that might be
> different from a standard Red Hat 8 install?

It is an upgraded Red Hat 7.2 system.

The Keyboard Layout Switcher Preferences applet in the panel
seems to correspond to the /usr/libexec/gkb-applet-2 process.
This executable comes from the gnome-applets-2.0.1-6 RPM,
which was built on porky.devel.redhat.com.

Under 'qc-2' as well as 'us', xev reports that:
- the tab key produces keycode 23 (keysym 0xff09, Tab);
- the shift+tab key produces keycode 50 (keysym 0xffe1, Shift_L)
  then keycode 23 (keysym 0xff09, Tab).


Comment 3 Owen Taylor 2003-06-10 22:28:54 UTC
Unfortunately, the GKB keymaps tend to be a little poorly maintained;
we'll eventually be switching to an applet called 'gswitchit' which
uses the keymaps distributed with XFree86.

See:

 http://bugzilla.gnome.org/show_bug.cgi?id=73423

for why the above doesn't work with GTK+.

 http://bugzilla.gnome.org/show_bug.cgi?id=82412

For fixing the GKB keymaps.



Note You need to log in before you can comment on or make changes to this bug.