After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 564861 - Windows switching is not proper when keyboard is in Russian mode
Windows switching is not proper when keyboard is in Russian mode
Status: RESOLVED DUPLICATE of bug 583822
Product: Sawfish
Classification: Deprecated
Component: Window Manager
Other All
: Normal normal
: 1.5.x
Assigned To: sawfish-maint
Depends on:
Reported: 2008-12-17 14:28 UTC by Victor Porton
Modified: 2010-07-31 06:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Victor Porton 2008-12-17 14:28:22 UTC
Please describe the problem:
I use Gnome and Gnome Keyboard Preferences to have two keyboard layouts, "USA" and "Russia Typewriter".

When I switch (I do this pressing CapsLock key) to "Russia Typewriter" layout, windows switching using Alt+Tab (I configured M-TAB to do "Cycle windows in sawfish-ui) is not working properly.

I press Alt and holding it pressed press Tab, this time it is working properly, the windows are switched. The bug comes when I press Tab second time (continuing to hold Alt). This time (when I press Tab second time), windows switching does not work. Instead it seem to pass Tab key press to the active window.

Steps to reproduce:
1. Open at least three windows.
2. Switch to Russian keyboard layout.
3. Holding Alt pressed, press Tab two times.

Actual results:
Switches windows once and then sends Tab key to the second window.

Expected results:
Should switch to the third window.

Does this happen every time?

Other information:
Comment 1 Christopher Roy Bratusek 2008-12-17 19:44:11 UTC
did you try with an empty configuration?

( mv ~/.sawfish* ~/Desktop/ && killall -qw sawfish && metacity )
( rm -rf ~/.sawfish* && killall -qw metacity && sawfish )

... those two steps to clean up.

if it works now, it's an configuration issue.

( rm -rf ~/.sawfish* && mv ~/Desktop/.sawfish* ~/ )

... to restore your configuration
Comment 2 Ildar 2009-10-16 11:47:32 UTC
Titlebar buttons do not react when I switch to non-English XKB layout (in my case kz(ruskaz)). I.e. when I press a button (minimize), nothing happens and just the tooltip appears.
Clear config used.
Comment 3 Christopher Roy Bratusek 2009-10-16 17:46:52 UTC
what X.Org version? which keyboard driver (kbd, evdev)? what is the exact previous and later layout (en_US, en_GB -> kz_?).
Comment 4 Ildar 2009-10-16 18:38:35 UTC
$ rpm -q xorg-server xorg-drv-evdev xorg-drv-keyboard 

$ setxkbmap -print
xkb_keymap {
	xkb_keycodes  { include "evdev+aliases(qwerty)"	};
	xkb_types     { include "complete"	};
	xkb_compat    { include "complete"	};
	xkb_symbols   { include "pc+us+kz(ruskaz):2+inet(evdev)+group(ctrl_shift_toggle)+level3(ralt_switch)"	};
	xkb_geometry  { include "pc(pc104)"	};

from log:
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(II) LoadModule: "evdev"
(II) Loading /usr/lib/X11/modules/input/
(II) Module evdev: vendor="X.Org Foundation"
        compiled for 1.6.3, module version = 2.2.5
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 4.0
(**) AT Translated Set 2 keyboard: always reports core events
(**) AT Translated Set 2 keyboard: Device: "/dev/input/event1"
(II) AT Translated Set 2 keyboard: Found keys
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type:
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"
Comment 5 Teika Kazura 2010-01-26 08:09:15 UTC
See bug 583822 (, since it contains additional info. Please mark this as "duplicate"
Comment 6 Ildar 2010-02-17 07:16:28 UTC
With 1.6 problem is still there.
Comment 7 Teika Kazura 2010-02-20 06:38:18 UTC
Please read bug 583822. The fix gets planned.
Comment 8 Christopher Roy Bratusek 2010-07-31 06:12:53 UTC

*** This bug has been marked as a duplicate of bug 583822 ***