Bug 540494

The same happens in installed system if one chooses Russian layout during installation, with the only difference that Ctrl+C/Ctrl+Z produce Russian letters 'с' and 'я'. This is because keyboard layouts seem to be "ru,us" instead of "us,ru".

gnome-terminal is not the only affected application, most of keyboard shortcuts cease to work in all KDE applications. For example, try Ctrl+T in Konqueror or Ctrl+O in KWrite.

Here is part of /var/log/YaST2/y2log:

2009-09-22 07:37:03 <1> linux(2663) [YCP] Misc.ycp:194 .sysconfig.keyboard.YAST_KEYBOARD: 'russian,pc104'
2009-09-22 07:37:03 <1> linux(2663) [YCP] Keyboard.ycp:609 current_kbd russian model pc104
2009-09-22 07:37:03 <1> linux(2663) [YCP] Keyboard.ycp:499 Setting keyboard to: <russian>
2009-09-22 07:37:03 <1> linux(2663) [YCP] Keyboard.ycp:298 keyboard model used: pc104
2009-09-22 07:37:03 <1> linux(2663) [YCP] Keyboard.ycp:510 Description for keyboard <russian>: <["Russian", $["ncurses":"ruwin_alt-UTF-8.map.gz"]]>
2009-09-22 07:37:03 <1> linux(2663) [YCP] Keyboard.ycp:521 x11data=$["Apply":"-variant winkeys, -layout ru,us -option grp:ctrl_shift_toggle,grp_led:scroll -model microsoftpro", "XkbLayout":"ru,us", "XkbModel":"microsoftpro", "XkbOptions":"grp:ctrl_shift_toggle,grp_led:scroll", "XkbVariant":"winkeys,"]
2009-09-22 07:37:03 <1> linux(2663) [YCP] Keyboard.ycp:624 Restored data (sysconfig) for keyboard: <russian>

Just out of curiosity: are you running binary nvidia blob driver version 180.35?

In this case: http://www.nvnews.net/vbulletin/showthread.php?t=128959&page=2

As for me, I simply boot from LiveCD without any restricted drivers on it.

I think this will be fine for a maintenance update - no idea what it is. But you could test a KDE live cd and see if it's something common to GNOME and KDE

I've tested KDE4 live CD. Keyboard shortcuts in KDE applications (e.g. Ctrl+O in KWrite) don't work.

setxkbmap -print says:

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete+ledscroll(group_lock)"        };
        xkb_symbols   { include "pc+ru(winkeys)+us:2+inet(evdev)+group(ctrl_shift_toggle)"      };
        xkb_geometry  { include "microsoft(natural)"    };
};

it should be "...us+ru(winkeys)...", not "...ru(winkeys)+us..."

So it looks like a X bug, according to comment #5.

It has always been requested ru being the first keyboard layout instead of the second one before. Reverting that again I'm sure users are going to complain. WONTFIX.

(In reply to comment #7)
Ending up with totally broken keyboard shortcuts? Great!

(In reply to comment #7)
> It has always been requested ru being the first keyboard layout instead of the
> second one before. Reverting that again I'm sure users are going to complain.
> WONTFIX.

Ha. 
Ha-ha.
MWA-HA-HA. MWAHAHHHAHAHAHAHHHA!
ROFL! ROFL! ROFL!
You rock. Your maner "We wouldn`t fix it because of FUCK YOU" rocks.
Simply rate what is now happening:
1. We have a bug. It touches only a certain category of users - but it is VERY important for it.
2. We have an ULTRA-SIMPLE work-around. It is not a solution; but it makes the system work for this - why not use it?
3. This category of users requests this work-around for their own convenience.
NAME ME AT LEAST ONE REASON FOR REJECTION?
Your brain of ciliate shoe couldn`t do it? Ok, I can help you: the only reason is that you are a fucking nazi.
I am happy that my great-grandfather and all my country have shown you where all of you should sit - there is no place for nazis in our world.
It is a 'most user-friendly distribution'? Even Ubuntu developers are not so idiotic, as you are. They are incompetent to, but they don`t make a policy of discrimination.
I will ask the Сourt of Human Rights. You will be destroyed. You'll never see a normal work, you`ll go to sweep the yard. Make your direct thy duty.
You are dangerous for all the Linux community. "Freedom? Choice? FUCK YOU!" With such members we will always have 1% of desktops - do you really want it?

I won't comment on this one, others might do.

Anyway, could someone explain to me why one would expect Ctrl-C/Ctrl-Z to behave in a terminal as desktop shortcut (shortcut for what?) instead of the usual meaning in a shell, i.e. abort the current task (Ctrl-C)/ push the foreground job into the background (Ctrl-Z). It doesn't make much sense to me.

I've tested the usual meaning of Ctrl-C/Ctrl-Z in xterm and konsole with keyboard layout combination ru,us. It works fine. The only terminal, I could find, where it doesn't work was gnome-terminal. Thus this looks more like an issue in gnome-terminal than a general X issue. I cannot reproduce non-working KDE keyboard shotcuts in any KDE application. Reassigning again to GNOME component therefore.

In gnome-terminal Ctrl+C/Ctrl+Z produces letters 'с' and 'я' as Arseniy mentioned before.

Moot point: i can give you another test-case.
Launch dolphin and try to use 'Ctrl+T' keybinding for opening a new tab. It doesn`t work to.
I am not quite familiar with xkb debugging, but it seems more like a XKB bug.

(In reply to comment #11)
> I cannot reproduce non-working KDE keyboard shotcuts in any KDE application.
But I can :-/

(In reply to comment #9)
> (In reply to comment #7)
> > It has always been requested ru being the first keyboard layout instead of the
> > second one before. Reverting that again I'm sure users are going to complain.
> > WONTFIX.
> 
> Ha. 
> Ha-ha.
> MWA-HA-HA. MWAHAHHHAHAHAHAHHHA!
> ROFL! ROFL! ROFL!
> You rock. Your maner "We wouldn`t fix it because of FUCK YOU" rocks.
> Simply rate what is now happening:
> 1. We have a bug. It touches only a certain category of users - but it is VERY
> important for it.
> 2. We have an ULTRA-SIMPLE work-around. It is not a solution; but it makes the
> system work for this - why not use it?
> 3. This category of users requests this work-around for their own convenience.
> NAME ME AT LEAST ONE REASON FOR REJECTION?
> Your brain of ciliate shoe couldn`t do it? Ok, I can help you: the only reason
> is that you are a fucking nazi.
> I am happy that my great-grandfather and all my country have shown you where
> all of you should sit - there is no place for nazis in our world.
> It is a 'most user-friendly distribution'? Even Ubuntu developers are not so
> idiotic, as you are. They are incompetent to, but they don`t make a policy of
> discrimination.
> I will ask the Сourt of Human Rights. You will be destroyed. You'll never see a
> normal work, you`ll go to sweep the yard. Make your direct thy duty.
> You are dangerous for all the Linux community. "Freedom? Choice? FUCK YOU!"
> With such members we will always have 1% of desktops - do you really want it?

Hi Paul, 

we at the openSUSE project have in our Guiding Principles [1] apart from other stuff 'respect for others and their work'. Do you think your above shown behaviour qualifies for this? Your behaviour is offending and everything else then constructive. Please read the Guiding Principles and appologise to Stefan. You're very welcome to participate here but not in that way. 

Best
Michael 

[1] http://en.opensuse.org/Guiding_Principles

I really don`t think that this bug should be ignored and marked 'WONTFIX' - it is very important for a big count of users world-wide (in fact, it touches the most part of Eastern Europe).
But I agree, my tone was highly offensive, inadquate and unacceptable for others. It seems like I misunderstood Stefan (mostly, it was a desire to draw attention to the problem; my bad mood triggered it too) and I apologize to him.

(In reply to comment #17)
> I really don`t think that this bug should be ignored and marked 'WONTFIX' - it
> is very important for a big count of users world-wide (in fact, it touches the
> most part of Eastern Europe).
> But I agree, my tone was highly offensive, inadquate and unacceptable for
> others. It seems like I misunderstood Stefan (mostly, it was a desire to draw
> attention to the problem; my bad mood triggered it too) and I apologize to him.

In most free software projects this would have drawn attention to yourself more than to the problem. And once one has obtained the reputation of a troll this person will have a heck of a time to be taken seriously again.

People have a lot of expectations on openSUSE, yet, our team is way too understaffed to satisfy all those, therefore answers may not be all that detailed. We could really use more help from the community debugging all the issues that get reported.

I've looked into this problem so I'm taking over here now.
1. I don't see why switching "ru(winkeys)+us:2" around would make any 
   difference.
   The '+' asks for an override, yet the ':2' applies the us keymap to the  
   Group2 keymap. Since ru(winkeys) doesn't add any symbols to group2 the order 
   shouldn't make a difference.
   To verify this I've pasted the entire setxkbmap output from comment #5 into 
   a file and ran: 'xkbcomp <filename> $DISPLAY' subsequently I dumped the 
   entire mapping with 'xkbcomp $DISPLAY - > file1'. I then switched around 
   the two entries loaded and dumped the keymap again. A diff of both maps  
   showed that they are identical (except for the very line where things were
   swapped around).
   To change the layout group one needs to press ctrl-shift. Doing this in 
   gnome-terminal yields the right behavior when pressing ctrl-Z or ctrl-C.

2. Like Stefan I've tested xterm, konsole and gnome-terminal. Only gnome-
   terminal exhibits the wrong behavior when pressing ctrl-Z or ctrl-c in
   group1 (Cyrillic layout). Apparently the reason for this is that gnome-
   terminal is only looking for the keysym of the 'z' or 'c' key which is 
   however Cyrillic-ya or Cyrillic-es. The right way to deal with this would
   be to check if any symbol for the key pressed when Ctrl is held is 'z' 
   or 'c'.

3. The behavior of dolphin as descried in comment #13 looks like a general bug
   in KDE: I don't seem to be able to use any of the Ctrl shortcuts in dolphin 
   - no matter what keyboard layout I have set.

(In reply to comment #18)
> 1. I don't see why switching "ru(winkeys)+us:2" around would make any 
>    difference.
>    The '+' asks for an override, yet the ':2' applies the us keymap to the  
>    Group2 keymap. Since ru(winkeys) doesn't add any symbols to group2 the order 
>    shouldn't make a difference.
I mean that correct is "pc+us+ru(winkeys):2+..." which is obviously not the same. Ctrl+O in KWrite and Ctrl+T in Dolphin work with this setting.

(In reply to comment #18)
> 3. The behavior of dolphin as descried in comment #13 looks like a general bug
>    in KDE: I don't seem to be able to use any of the Ctrl shortcuts in dolphin 
>    - no matter what keyboard layout I have set.

In Qt, actually. And I'm not sure that it is a bug.

(In reply to comment #19)
> I mean that correct is "pc+us+ru(winkeys):2+..." which is obviously not the
> same. Ctrl+O in KWrite and Ctrl+T in Dolphin work with this setting.

Ok, that's different. It would put the ru keys into group2 which is probably not what the standard user in Russia wants.
We have had reports requesting ...ru(winkeys)+us:2...
I still believe that the keyboard shortcut issue should be fixed in the toolkit (Qt) as well as in gnome-terminal.

(In reply to comment #21)
> I still believe that the keyboard shortcut issue should be fixed in the
> toolkit (Qt) as well as in gnome-terminal.
I could even make a patch for Qt, but affected software is not limited to Qt and gnome-terminal. There's also a lot of applications which are not in openSUSE main repository, and it's impossible to fix all of them.

(In reply to comment #22)
> (In reply to comment #21)
> > I still believe that the keyboard shortcut issue should be fixed in the
> > toolkit (Qt) as well as in gnome-terminal.
> I could even make a patch for Qt, 

Could you attach it?

> but affected software is not limited to Qt and gnome-terminal. 

Could you give us examples?

> There's also a lot of applications which are not in openSUSE main repository, 
> and it's impossible to fix all of them.

First we need to see examples of other affected applications.

(In reply to comment #23)
> Could you attach it?
No, I haven't made those changes to Qt yet.

> Could you give us examples?
ZDaemon, Maple.

(In reply to comment #24)
> > Could you give us examples?
> ZDaemon, Maple.

Thanks. Where can I find these?

both gtk and Qt/KDE have problem with shortcut when first layout non us one.

this issue known at least since 2005, here discussion in gnome upstream bugzilla

https://bugzilla.gnome.org/show_bug.cgi?id=162726

http://helgo.net/simon/hacking/shortcut.html

bug affected not only russian keyboard layot, but all others, where us layout not first

Ok.
US keyboard layout will again as primary... also "us,ru".

(In reply to comment #25)
> Thanks. Where can I find these?

ZDaemon: http://web.archive.org/web/20040823092115/fenixhost.com/doom/
Maple (http://maplesoft.com) is commercial software.

However, there must be more examples I didn't happen to know about.

(In reply to comment #26)
> both gtk and Qt/KDE have problem with shortcut when first layout non us one.
> 
> this issue known at least since 2005, here discussion in gnome upstream
> bugzilla
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=162726
> 
> http://helgo.net/simon/hacking/shortcut.html
> 
> bug affected not only russian keyboard layot, but all others, where us layout
> not first

Thanks. So apparently this is a long standing issue with most toolkits affected. :-( This begs the question why there has been requests at all to make "ru" the primary keyboard layout. It makes no sense to me. Anyway, there is not much choice at the moment and I'm afraid this issue will never get fixed in the toolkits.

Switching to "us,ru" again.

(In reply to comment #30)
> 
> Thanks. So apparently this is a long standing issue with most toolkits
> affected. :-( This begs the question why there has been requests at all to make
> "ru" the primary keyboard layout. It makes no sense to me. Anyway, there is not
> much choice at the moment and I'm afraid this issue will never get fixed in the
> toolkits.
> 
> Switching to "us,ru" again.

Stefan, can you still locate the ticket which requested the change to ru,us?

*** Bug 510977 has been marked as a duplicate of this bug. ***